Tracking issue for breaking changes in 4.x

[ef4]

Opening this as a place to keep track of what is currently breaking between 3.x (stable branch) and the upcoming 4.x (main branch).

Planned breaking changes in 4.x

• [x] modifying app code via broccoli is not going to be supported
• [x] new index.html location and format required
• [x] explicit babel config and vite (or webpack) config required
• [x] strict ES module evaluation order has made some things more eager than before
• [x] the EMBER_ENV will be controlled via Vite's --mode argument.
• [x] the app is responsible for the config module, content for 'config-module' code must be moved on the app-side
• [x] the app is responsible for the app-boot module, content for 'app-boot' code must be moved on the app-side
• [x] serverMiddleware hook is not supported.
• [ ] AMD loader will be completely gone

Currently breaking behaviors that we're working on

• [ ] Embroider CI is currently only testing against ember canary. We plan to expand support backward again but haven't decided how far.
• [ ] we skipped tests for app.import with custom outputPath. We may or may not keep support for this feature.
• [ ] #1965
• [ ] webpack support is gone right now, we intend to do an inverted-control version of webpack too.
• [ ] We needed to skip some tests in windows because the build was timing out. We should do some basic analysis why things are running so slowly (or hanging) and see if we can re-enable these tests
• [ ] we've skipped engines tests and they need to be re-enabled and fixed before release
• [ ] we've skipped fastboot-app-test and they need to be re-enabled and fixed before release (with possible new way of running fastboot after a vite build)
• [ ] the new format for the env config doesn't support !storeConfigInMeta

Things to clean up before release

• [ ] //TODO move the extra forwardslash handling out into the vite plugin

Things we may want to break but haven't yet

• [ ] staticAddonTrees and staticAddonTestSupportTrees set to false was intended as a more-likely-to-work initial adoption mode. But they break things at least as often as they help, because they aggressively pull files into the build that can have problems. People have have a better adoption experience if we always keep them true and instead document how to identify when some small number of modules are not found at runtime.

[mansona]

AMD loader will be completely gone

Is this done now? or do you mean the extra work that actually removes the loader?

[ef4]

I mean we should finish landing https://github.com/embroider-build/embroider/pull/2103, and then ensure that loader.js is not in /@embroider/core/vendor.js.

In whole apps I've been testing under vite there's nothing in the AMD loader anyway.

[bwbuchanan]

How is route-splitting intended to work with ember-resolver explicit modules? I've been experimenting with using the vite blueprint in one of my apps, and after updating to the latest everything from this week, most of my routes stopped working. After some hours of debugging, it appears that the cause was making this change in app.ts:

  override Resolver = Resolver.withModules(compatModules);

Because @embroider/virtual/compat-modules doesn't get updated when lazy-loaded routes are loaded, the resolver never finds them.

I had to add something like this to the route files to get them to be found:

// @ts-expect-error No typedefs
import compatModules from '@embroider/virtual/compat-modules';
compatModules['my-app/routes/admin'] = Admin;

[ef4]

Ah, good catch. We must lack tests for that combination of settings.