At present, we generate two separate entrypoints to hand to webpack (one for app, one for tests). We follow the same pattern that normal ember apps do, such that the tests are allowed to assume that the app is necessarily always loaded first, so a dependency that is used by the tests should be left out of the test entrypoint if it's also used by the app.
However, it would be better to switch to layering the tests and app the way embroider does, by creating an explicit dependency from the test entrypoint to the app entrypoint. This lets webpack handle the deduplication, and it can take into account more resolution detail than we can.
A case that fails today is having app code that imports from "some-dependency/thing.js" and test code that imports from "some-dependency/thing". Both resolve to the same module, but it will actually load and execute twice because ember-auto-import fails to deduplicate it.
At present, we generate two separate entrypoints to hand to webpack (one for app, one for tests). We follow the same pattern that normal ember apps do, such that the tests are allowed to assume that the app is necessarily always loaded first, so a dependency that is used by the tests should be left out of the test entrypoint if it's also used by the app.
However, it would be better to switch to layering the tests and app the way embroider does, by creating an explicit dependency from the test entrypoint to the app entrypoint. This lets webpack handle the deduplication, and it can take into account more resolution detail than we can.
A case that fails today is having app code that imports from "some-dependency/thing.js" and test code that imports from "some-dependency/thing". Both resolve to the same module, but it will actually load and execute twice because ember-auto-import fails to deduplicate it.