Extract preprocessor and babel plugin into their own packages

[ef4]

I think we should take the preprocessor and the babel-plugin and extract them from this package into their own libraries.

We don't necessarily want every app into the future to be locked into having a dep on ember-template-imports, for a few reasons:

• we will probably want a better name for it before it goes into the default blueprint. The user-facing feature is "template tag", not "template imports". Managing this transition is harder if multiple packages (like ember-template-lint and estlint-plugin-ember) have peer deps on it. Those peer deps are only needed because they need access to the preprocessor, and would be happy to just have deps on the library if it existed.
• we want people to be able to see and manage their own build plugins in environments like embroider's upcoming vite support. In that situation, having ember-template-imports is unhelpful -- it has as bunch of legacy broccoli things that aren't relevant. The user really only wants the babel-plugin to put their babel config and a packager-specific plugin that can depend on the preprocessor library.

[NullVoxPopuli]

List of consumers' locations that would need updating after the extraction occurs:

• The <template> rollup plugin
  • https://github.com/NullVoxPopuli/rollup-plugin-glimmer-template-tag/blob/main/packages/rollup-plugin-glimmer-template-tag/src/rollup-plugin.js#L10
• ember-template-lint
  • https://github.com/ember-template-lint/ember-template-lint/blob/b4433e9439f3c555b3c4beb56c34bfed18a423b5/lib/extract-templates.js#L1
  • https://github.com/ember-template-lint/ember-template-lint/blob/b4433e9439f3c555b3c4beb56c34bfed18a423b5/test/unit/extract-templates-test.js#L2
• eslint-plugin-ember
  • https://github.com/ember-cli/eslint-plugin-ember/blob/a714b468832b7fc26da020513c7ef491959e211b/lib/preprocessors/glimmer.js#L5
  • https://github.com/ember-cli/eslint-plugin-ember/blob/a714b468832b7fc26da020513c7ef491959e211b/lib/config/recommended.js#L2
• ember-repl
  • https://github.com/NullVoxPopuli/limber/blob/273f1626927d6d467de45c9d08c406adb353fcdc/packages/ember-repl/addon/cjs/index.ts#L7
• Glint
  • https://github.com/typed-ember/glint/blob/3b0d3ab78765c2b39e25e09788597609740cacad/packages/environment-ember-template-imports/-private/environment/preprocess.ts#L2

[NullVoxPopuli]

Should the babel plugin become part of https://github.com/emberjs/babel-plugin-ember-template-compilation/ ?

[ef4]

Yes, I'm open to the idea of merging the Babel part into babel-plugin-ember-template-compilation.

[ef4]

(It would not a separate plugin, it would be a feature in the existing plugin.)

[achambers]

So, started extracting preprocess-embedded-templates.ts and started to realize that there are a number of inter-dependencies to the files I'm trying to extract and between those files themselves. I'm currently taking the bullish approach and just extracting and duplicating to get things to work but going to need to work out the most appropriate way to do this before shipping.

[NullVoxPopuli]

a good chunk of stuff is simpler if you delete all the template-literal-transform code, as in: #146

you'll start to see that some abstractions (consts, functions, etc) are no longer needed, or only do a very focused thing.

Hope this helps!

[achambers]

[UPDATE] Here's an attempt at extracting the preprocess-embedded-templates code: https://github.com/achambers/preprocess-ember-template

I have verified this locally against ember-template-imports and ember-template-lint but still have some questions. Need to also verify against the other repos that depend on template imports currently.

One thing to note, have gone back to making this change against master instead if against #146 as removing support for hbs breaks ember-template-import as it still needs to be able to render a template that uses inline templates as per it's tests that use inline hbs in test files which, as far as I understand, is still a valid use case, for the time being at least.

[ef4]

Latest updates here:

• we have the preprocessor shipping in https://github.com/embroider-build/content-tag/
• babel-plugin-ember-template-compilation 2.1.0 shipped with built-in support for the babel part, since RFC 931 is merged
• we are using them in @embroider/addon-dev

Next steps:

• PR updates to ember-cli-babel bumping minimum babel-plugin-ember-template-compilation-plugin to 2.1.0 and adding @babel/plugin-transform-class-static-block alongside the other plugins that become mandatory when transpiling decorators.
• once those changes are in ember-cli-babel, we can update ember-template-imports PR use content-tag #182, and it can be a major release that documents the minimum ember-cli-babel version your app must have. (It will also be a major because it drops the preprocessor library, and its dependents should switch to using content-tag directly)

[achambers]

Hi @ef4 . Started to take a look at these next steps but am a little confused. Can you please clarify a couple of things?

PR updates to ember-cli-babel bumping minimum babel-plugin-ember-template-compilation to 2.1.0

I couldn't find babel-plugin-ember-template-compilation referenced in ember-cli-babel. It does seem to be used in ember-cli-htmlbars. Is that the repo I should be bumping the package?

adding @babel/plugin-transform-class-static-block alongside the other plugins that become mandatory when transpiling decorators.

Should this still happen in ember-cli-babel? I see that the likes of @babel/plugin-proposal-class-properties are also referenced in ember-cli-htmlbars however they seem to just be used in tests and are devDependencies where as they are dependencies in ember-cli-babel. I suspect this item remains as is but I just wanted to clarify.

once those changes are in ember-cli-babel, we can update ember-template-imports

Assuming we are making the changes to both ember-cli-babel and ember-cli-htmlbars, I guess we'll need to bump both packages in ember-template-imports. Confirm?

[mansona]

should we close this issue and track our work in emberjs/tracking-polaris#33 now?

[NullVoxPopuli]

We still have the other tools to propagate changes to, but we did it! Go team!