Allow AST plugins to manipulate Javascript scope #5
Conversation
This spikes out the ability for AST plugins to access Javascript imports and expression. Still needs more practical testing. Does not support Ember < 3.28 because that's where we gained the option to use lexically scoped values in non-strict templates.
|
The usefulness of this will depend on getting ember-cli-htmlbars to process all templates through babel-plugin-ember-template-compilation. At the moment:
|
|
(All those cases already work in embroider, but addons can't realistically adopt if we don't make it work in classic builds too) |
Classically, standalone templates got a dedicated preprocessor that had nothing to do with Javascript transpilation. Later came inline templates that appear inside Javascript. Those were handled as a totally separate code path from the standalone templates. To this day, there are two different code paths for handling these two cases. But at this point, templates-inside-javascript are the foundational primitive that is aligned with [where Ember is heading](emberjs/rfcs#779), because they have access to Javascript scope and this solves a lot of problems. We can treat standalone HBS as just a degenerate kind of JS that is easily up-compiled via a pure function, allowing them to go down the Javascript code path and allowing us to drop all the old code path. This also makes it easier to support new features like [AST transforms that can manipulate Javascript scope](emberjs/babel-plugin-ember-template-compilation#5). Embroider already [implemented this same pattern](embroider-build/embroider#1010).
|
I confirmed in a test app that ember-cli/ember-cli-htmlbars#749 is enough to make this new feature work in all templates including the stand-alone, non-colocated ones. |
I think that's less ambiguous.
|
ember-cli-babel 6.1 shipped with the changes required to make this useful in all templates. |
|
My next action here is to test this new API in Embroider, since we already do the same class of things in a less elegant way. |
Not just the precompile function.
Source to source mode
So we can rely on it to handle nameHint sanitization
Imports are legal anywhere and their order doesn't really matter, but it looks weird when they are interleaved with other statements.
|
Embroider is now happily refactored onto this feature as the foundational primitive for getting static components, helpers, and modifiers into templates. See embroider-build/embroider#1276 |
This spikes out the ability for AST plugins to access Javascript imports and expression.
Still needs more practical testing.
Does not support Ember < 3.28 because that's where we gained the option to use lexically scoped values in non-strict templates.