Common chunks can end up in both vendor.js and test-support.js

[ef4]

This comment has a working example that induces a shared chunk to go into both vendor.js and test-support.js, which is a particular problem for graphql because it checks for duplication.

[ef4]

We already do the right thing with your own actual imports. But second-order and deeper dependencies can get split into common chunks by webpack, and we need to also deal with those.

If we want to stick to adding our things into the normal ember JS files, we're going to need to stop treating "tests" as an entrypoint and start treating it like a lazy chunk on top of the app entrypoint, because that is a more accurate match for the relationship between vendor.js and test-support.js.

[josemarluedke]

Any new developments in this area? We are blocked in ember-graphql/ember-apollo-client#175 by this issue. Thanks.

[ef4]

Not exactly. I did recently fix this same issue in embroider (which is relevant because ember-auto-import is in some sense a polyfill for the full embroider).

But it's more annoying to fix here, because we're still trying to fall into the existing ember bundles.

This and some other areas in auto-import would get a lot simpler if we are OK with having a separate script tag for the auto-imported stuff.

[buschtoens]

This and some other areas in auto-import would get a lot simpler if we are OK with having a separate script tag for the auto-imported stuff.

Personally, I would be A-OK with it. It could potentially even get us some caching benefits between deployments, if the auto-imported assets don't change, right?

If we use the contentFor hook, we can add the <script> tag without any manual user involvement.

But it sounds like you're having some reservations?

[ef4]

I think it could be a breaking change for some people's deployment setups. They were expecting to only need to deploy exactly the JS files they have now, not extra ones.

This is not a big deal when the app itself opts in to using ember-auto-import. But sometimes its one of their addons that adopts ember-auto-import, and then the app is forced to deal with it anyway.

I would hope everybody just deploys all the files in dist. But the fact that ember-cli offers a weird degree of customizability over what your bundles are named and where they go makes me think people much be relying on specific structures.

[buschtoens]

Do you think it would be feasible to keep this configurable for the time being?