ember-svg-jar hbs strategy broken

Hello 👋🏼 recently the ember-svg-jar new hbs strategy got merged 🎉, native dynamic imports for template only components generated from svgs at build time, thanks @ef4 for the help back then in contributors workshop, here’s the strategy: https://github.com/ivanvotti/ember-svg-jar/pull/186! embroider is on the ember-try matrix and it passed before merging…

Until I added a follow up PR https://github.com/ivanvotti/ember-svg-jar/pull/189 with an example on the dummy/app/templates/application.hbs and a found out that its actually not embroiderSafe()… I started by changing the code to make it statically analyzable i.e. not using {{component}} or string invokation…

The dynamic import part: https://github.com/betocantu93/ember-svg-jar/blob/15a250980af94e4c1d20b8240de56ccbd8748d58/addon/components/svg/index.js#L33

The ensureComponent part: https://github.com/betocantu93/ember-svg-jar/blob/15a250980af94e4c1d20b8240de56ccbd8748d58/addon/components/svg/index.js#L51

The template usage part: https://github.com/betocantu93/ember-svg-jar/blob/15a250980af94e4c1d20b8240de56ccbd8748d58/addon/components/svg/index.hbs#L2

But it seems there are a few roadblocks for this to work with embroider.

Reading through the spec, I “know” or noticed a few things, please correct me if wrong:

1. Support for treeForAddon and treeForPublic is dropped, since this is v1 addon I can still see the generated components in /dist/ember-svg-jar/components/** with a subtle difference, the templates are not compiled 🤔 <-- not sure if this is actually a compat bug
2. Dynamic import just don’t work, because we have to dynamically build the asset path at runtime cuz of the dynamic nature of these components and accounting for fingerprinting and such.
3. A little jump in to the future, packages must declare their public-assets statically for addon metadata, this is something this hbs strategy would need to somehow build a la carte(?), but overall I understand v2 addon just don’t generate stuff at build time anymore.

If I understood the overall spec correctly, the hbs strategy would actually need to be refactored and exposed as an API or something to the host app for it to manually generate them i.e generate and add them to /public manually on ember-cli-build.js, but even that is feasible (why not), the dynamic import, dynamic asset path constraint, still blocks this.

There’s no rush for anything, but I would love to get some guidance on what’s need to be done or some help designing the solution and work or co-work on it 😄

Thanks for the amazing work!

P.D I probably miss understood many parts of the spec.

[ef4]

A thing that might help as an example is on this branch I’m currently working on. It includes an even simpler hbs loader for templates:

https://github.com/embroider-build/embroider/blob/template-compilation/packages/hbs-loader/src/index.ts

That uses a string-to-string transform here:

https://github.com/embroider-build/embroider/blob/template-compilation/packages/shared-internals/src/hbs-to-js.ts

Which relies on stacking several webpack loaders together, so that first we go hbs-to-js and then we apply our babel to the JS.

You could do a similar pattern to rewrite svg to JS-with-embedded-templates.

[betocantu93]

Hello @ef4 hope you doing fine, finally back at this after a few months of backlog.

When you have time and if possible would you mind showing me a little loader Proof of concept that would take strings and compile them to ToC, say for .svg ext? I genuinely tried a bunch of configurations. I can surely take it from there.

Thanks!