ember-engines
Earlier `<LazyMount>` migrations
Heyo 👋
This was my original <LazyMount> migration, to support embroider and classic builds. I modernized the component with a glimmer component (such no positional params) but named blocks and updated the loading of the engine with something that works under embroider as well as requirejs land.
I think, the loading part is the core of this PR.
While doing so and looking at the "modernizations" to <LazyMount> that sorta diverge from {{mount}} - I think it might be better to revert this <LazyMount> component back into a {{lazy-mount}} helper.
Either way should be fine, but keeping the helper as an ember component is probably the worst decision to be made here.
@gossi could you please add tests to it including embroider scenario?
embroider scenario will be added as part of the ember v5 work there are no currently viable solutions to make this work under embroider so the tests which are highly desirable would have to be skipped for those ember try scenarios
The idea of this PR was to push my earlier investigations, as such the PR is not targeted at the main branch, but the lazy-mount branch.
That is, take from my PR what you need: Merge it into or copy the relevant lines and close it afterwards.
I expect final implementation and testing to happen at #887
What I could offer though: I do have the component and the service available as (g)ts 😬
@gossi curious which ember source you're on and which embroider flags you have one + embroider version the code on this branch is likely incidentally working because of requirejs being available under certain versions/configurations of ember-source/embroider even with gts it will only work by requirejs existing and having the correct entries
the import statement does not work now and will never work in the future as written no matter the build tool used
import(`${dynamicSegmentFirst}/something`) is an error no matter where you try to use it.
only something like import(`known/static/path/first/${dynamicSegment}/something/something`) could technically work
Ah, I did use the addon v2 blueprint and used the test-app within there (with "ember-source": "~5.7.0" as dep).
In ember-cli-build.js I was trying these both approaches:
// const { maybeEmbroider } = require('@embroider/test-setup');
// return maybeEmbroider(app);
return app.toTree();
But I see, it only has "@embroider/test-setup": "^3.0.1" as dev-dependency, so the maybeEmbroider() afaik returns false then, so no embroider, but webpack.
our solution was to turn (lazy)mount engines into (v2) addons and let ember's build system take control of chunking (and also such loading). I stopped this PR then.
Probably I vote for deprecating them. However for continuing support they need to be migrated. Feel free to take over my PR. Consider this a PoC and start over, contribute to that, etc.
Probably I vote for deprecating them
Sorry, I think I didn't get your point. Why is it deprecated, if lazy-mount is a required feature for routeless engines to be lazy loading?