mirror of
https://github.com/discourse/discourse.git
synced 2024-12-03 18:23:39 +08:00
cbc28e8e33
(extracted from #23678) * Move Wizard back into main app, remove Wizard addon * Remove Wizard-related resolver or build hacks * Install and enable `@embroider/router` * Add "wizard" to `splitAtRoutes` In a fully optimized Embroider app, route-based code splitting more or less Just Work™ – install `@embroider/router`, subclass from it, configure which routes you want to split and that's about it. However, our app is not "fully optimized", by which I mean we are not able to turn on all the `static*` flags. In Embroider, "static" means "statically analyzable". Specifically it means that all inter-dependencies between modules (files) are explicitly expressed as `import`s, as opposed to `{{i18n ...}}` magically means "look for the default export in app/helpers/i18n.js" or something even more dynamic with the resolver. Without turning on those flags, Embroider behaves conservatively, slurps up all `app` files eagerly into the primary bundle/chunks. So, while you _could_ turn on route-based code splitting, there won't be much to split. The commits leading up to this involves a bunch of refactors and cleanups that 1) works perfectly fine in the classic build, 2) are good and useful in their own right, but also 3) re-arranged things such that most dependencies are now explicit. With those in place, I was able to move all the wizard code into the "app/static" folder. Embroider does not eagerly pull things from this folder into any bundle, unless something explicitly "asks" for them via `imports`. Conversely, things from this folder are not registered with the resolver and are not added to the `loader.js` registry. In conjunction with route-based code splitting, we now have the ability to split out islands of on-demand functionalities from the main app bundle. When you split a route in Embroider, it automatically creates a bundle/entrypoint with the relevant routes/templates/controllers matching that route prefix. Anything they import will be added to the bundle as well, assuming they are not already in the main app bundle, which is where the "app/static" folder comes into play. The "app/static" folder name is not special. It is configured in ember-cli-build.js. Alternatively, we could have left everything in their normal locations, and add more fine-grained paths to the `staticAppPaths` array. I just thought it would be easy to manage and scale, and less error-prone to do it this way. Note that putting things in `app/static` does not guarantee that it would not be part of the main app bundle. For example, if we were to add an `import ... from "app/static/wizard/...";` in a main bundle file (say, `app.js`), then that chunk of the module graph would be pulled in. (Consider using `await import(...)`?) Overtime, we can build better tooling (e.g. lint rules and babel macros to make things less repetitive) as we expand the use of this pattern, but this is a start. Co-authored-by: Godfrey Chan <godfreykfc@gmail.com>
59 lines
3.1 KiB
JavaScript
59 lines
3.1 KiB
JavaScript
// Webpack has bugs, using globalThis is the safest
|
|
// https://github.com/embroider-build/embroider/issues/1545
|
|
let { define: __define__, require: __require__ } = globalThis;
|
|
|
|
// Traditionally, Ember compiled ES modules into AMD modules, which are then
|
|
// made usable in the browser at runtime via loader.js. In a classic build, all
|
|
// the modules, including any external ember-auto-imported dependencies, are
|
|
// added to the loader.js registry and therefore require()-able at runtime.
|
|
//
|
|
// Overtime, the AMD-ness of the modules, the ability to define arbitrarily
|
|
// named modules and the ability to require any modules and even enumerate the
|
|
// known modules at runtime (require.entries/_eak_seen) became heavily relied
|
|
// upon, which is problematic. For one thing, these features don't align well
|
|
// with ES modules semantics, and it is also impossible to perform tree-shaking
|
|
// as the presence of a particular module could end up being important even if
|
|
// it appears to be unused in the static analysis.
|
|
//
|
|
// For Discourse, the AMD/loader.js mechanism is an important glue. It is what
|
|
// allows Discourse core/admin/plugins to all be separate .js bundlers
|
|
// and be "glued back together" as full module graph in the browser.
|
|
//
|
|
// For instance, a plugin module can `import Post from "discourse/models/post";
|
|
// because the babel plugin compiled discourse/models/post.js into an AMD
|
|
// module into app.js (`define("discourse/models/post", ...)`), which makes
|
|
// it available in the runtime loader.js registry, and the plugin module itself
|
|
// is also compiled into AMD with a dependency on the core module.
|
|
//
|
|
// This has similar drawbacks as the general problem in the ecosystem, but in
|
|
// addition, it has a particular bad side-effect that any external dependencies
|
|
// (NPM packages) we use in core will automatically become a defacto public API
|
|
// for plugins to use as well, making it difficult for core to upgrade/remove
|
|
// dependencies (and thus so as introducing them in the first place).
|
|
//
|
|
// Ember is aggressively moving away from AMD modules and there are active RFCs
|
|
// to explore the path to deprecating AMD/loader.js. While it would still be
|
|
// fine (in the medium term at least) for us to use AMD/loader.js as an interop
|
|
// mechanism between our bundles, we will have to be more conscious about what
|
|
// to make available to plugins via this mechanism.
|
|
//
|
|
// In the meantime Embroider no longer automatically add AMD shims for external
|
|
// dependencies. In order to preserve compatibility for plugins, this utility
|
|
// allows us to manually force a particular module to be included in loader.js
|
|
// and available to plugins. Overtime we should review this list and start
|
|
// deprecating any accidental leakages.
|
|
//
|
|
// The general way to use it is:
|
|
//
|
|
// import { importSync } from "@embroider/macros";
|
|
//
|
|
// loaderShim("some-npm-pkg", () => importSync("some-npm-pkg"));
|
|
//
|
|
// Note that `importSync` is a macro which must be passed a string
|
|
// literal, therefore cannot be abstracted away.
|
|
export default function loaderShim(pkg, callback) {
|
|
if (!__require__.has(pkg)) {
|
|
__define__(pkg, callback);
|
|
}
|
|
}
|