babel-plugin-ember-template-compilation

Babel plugin that implements Ember's low-level template-compilation API.

Requirements

• Node 12+ (when used in Node, but we also support in-browser usage)
• Babel 7
• the output works with ember-source 3.27+. For older Ember versions, see babel-plugin-htmlbars-inline-precompile instead.

Usage

This plugin implements precompileTemplate from RFC 496:

1import { precompileTemplate } from '@ember/template-compilation';

For backward compatibility, it also has an enableLegacyModules option that can enable each of these widely-used older patterns:

1import { hbs } from 'ember-cli-htmlbars';
2import hbs from 'ember-cli-htmlbars-inline-precompile';
3import hbs from 'htmlbars-inline-precompile';

Common Options

This package has both a Node implementation and a portable implementation that works in browsers.

The exported modules are:

• babel-plugin-ember-template-compilation: automatically chooses between the node and browser implementations (using package.json exports feature).
• babel-plugin-ember-template-compilation/browser: the core implementation that works in browsers (and anywhere else) without using any Node-specific APIs.
• babel-plugin-ember-template-compilation/node: the Node-specific implementation that adds the ability to automatically load plugins from disk, etc.

The options are:

1interface Options {
2  // The ember-template-compiler.js module that ships within your ember-source version. In the browser implementation, this is mandatory. In the Node implementation you can use compilerPath instead.
3  compiler?: EmberTemplateCompiler;
4
5  // The on-disk path to the ember-template-compiler.js module for our current
6  // ember version. You may set `compilerPath` or set `compiler`.
7  // This will get resolved from the current working directory, so a package name
8  // like "ember-source/dist/ember-template-compiler" (the default value) is acceptable. 
9  compilerPath?: string;
10
11  // Allows you to remap what imports will be emitted in our compiled output. By
12  // example:
13  //
14  //   outputModuleOverrides: {
15  //     '@ember/template-factory': {
16  //       createTemplateFactory: ['createTemplateFactory', '@glimmer/core'],
17  //     }
18  //   }
19  //
20  // Normal Ember apps shouldn't need this, it exists to support other
21  // environments like standalone GlimmerJS
22  outputModuleOverrides?: Record<string, Record<string, [string, string]>>;
23
24  // By default, this plugin implements only Ember's stable public API for
25  // template compilation, which is:
26  //
27  //    import { precompileTemplate } from '@ember/template-compilation';
28  //
29  // But historically there are several other importable syntaxes in widespread
30  // use, and we can enable those too by including their module names in this
31  // list. See `type LegacyModuleName` below.
32  enableLegacyModules?: LegacyModuleName[];
33
34  // Controls the output format.
35  //
36  //  "wire": The default. In the output, your templates are ready to execute in
37  //  the most performant way.
38  //
39  //  "hbs": In the output, your templates will still be in HBS format.
40  //  Generally this means they will still need further processing before
41  //  they're ready to execute. The purpose of this mode is to support things
42  //  like codemods and pre-publication transformations in libraries.
43  targetFormat?: 'wire' | 'hbs';
44
45  // Optional list of custom transforms to apply to the handlebars AST before
46  // compilation. See `type Transform` below.
47  transforms?: Transform[];
48}
49
50// The legal legacy module names. These are the only ones that are supported,
51// because these are the ones in widespread community use. We don't want people
52// creating new ones -- prefer `@ember/template-compilation` in new code.
53type LegacyModuleName =
54  | 'ember-cli-htmlbars'
55  | 'ember-cli-htmlbars-inline-precompile'
56  | 'htmlbars-inline-precompile';
57
58// Each transform can be
59//   - the actual AST transform function (this is the only kind that works in non-Node environments)
60//   - a path to a module where we will find the AST transform function as the default export
61//   - an array of length two containing the path to a module and an arguments object.
62//       In this case we will pass the arguments to the default export from the module and
63//       it should return the actual AST transform function.
64// All the path resolving happens relative to the current working directory and
65// respects node_modules resolution.
66type Transform = Function | string | [string, unknown];

JSUtils: Manipulating Javascript from within AST transforms

AST transforms are plugins for modifying HBS templates at build time. Because those templates are embedded in Javascript and can access the Javascript scope, an AST plugin may want to introduce some new things into Javascript scope. That is what the JSUtils API is for.

Your AST transform can access the JSUtils API via env.meta.jsutils. Here's an example transform.

1function myAstTransform(env) {
2  return {
3    name: 'my-ast-transform',
4    visitor: {
5      PathExpression(node, path) {
6        if (node.original === 'onePlusOne') {
7          let name = env.meta.jsutils.bindExpression('1+1', path, { nameHint: 'two' });
8          return env.syntax.builders.path(name);
9        }
10      },
11    },
12  };
13}

The example transform above would rewrite:

1import { precompileTemplate } from '@ember/template-compilation';
2precompileTemplate('<Counter @value={{onePlusOne}} />>');

To:

1import { precompileTemplate } from '@ember/template-compilation';
2let two = 1 + 1;
3precompileTemplate('<Counter @value={{two}} />', { scope: () => ({ two }) });

See the jsdoc comments in js-utils.js for details on the methods available.

Acknowledgement / History

This repo derives from https://github.com/ember-cli/babel-plugin-htmlbars-inline-precompile