2023-04-20 20:57:40 +08:00
|
|
|
{
|
|
|
|
|
"private": true,
|
|
|
|
|
"scripts": {
|
2023-09-14 19:25:06 +08:00
|
|
|
"postinstall": "./run-patch-package"
|
2023-04-20 20:57:40 +08:00
|
|
|
},
|
|
|
|
|
"workspaces": [
|
|
|
|
|
"admin",
|
|
|
|
|
"bootstrap-json",
|
2023-07-19 02:07:20 +08:00
|
|
|
"deprecation-silencer",
|
2023-04-20 20:57:40 +08:00
|
|
|
"dialog-holder",
|
|
|
|
|
"discourse",
|
|
|
|
|
"discourse-common",
|
|
|
|
|
"discourse-hbr",
|
DEV: convert I18n pseudo package into real package (discourse-i18n) (#23867)
Currently, `window.I18n` is defined in an old school hand written
script, inlined into locale/*.js by the Rails asset pipeline, and
then the global variable is shimmed into a pseudo AMD module later
in `module-shims.js`.
This approach has some problems – for one thing, when we add a new
V2 addon (e.g. in #23859), Embroider/Webpack is stricter about its
dependencies and won't let you `import from "I18n";` when `"I18n"`
isn't listed as one of its `dependencies` or `peerDependencies`.
This moves `I18n` into a real package – `discourse-i18n`. (I was
originally planning to keep the `I18n` name since it's a private
package anyway, but NPM packages are supposed to have lower case
names and that may cause problems with other tools.)
This package defines and exports a regular class, but also defines
the default global instance for backwards compatibility. We should
use the exported class in tests to make one-off instances without
mutating the global instance and having to clean it up after the
test run. However, I did not attempt that refactor in this PR.
Since `discourse-i18n` is now included by the app, the locale
scripts needs to be loaded after the app chunks. Since no "real"
work happens until later on when we kick things off in the boot
script, the order in which the script tags appear shouldn't be a
problem. Alternatively, we can rework the locale bundles to be more
lazy like everything else, and require/import them into the app.
I avoided renaming the imports in this commit since that would be
quite noisy and drowns out the actual changes here. Instead, I used
a Webpack alias to redirect the current `"I18n"` import to the new
package for the time being. In a separate commit later on, I'll
rename all the imports in oneshot and remove the alias. As always,
plugins and the legacy bundles (admin/wizard) still relies on the
runtime AMD shims regardless.
For the most part, I avoided refactoring the actual I18n code too
much other than making it a class, and some light stuff like `var`
into `let`.
However, now that it is in a reasonable format to work with (no
longer inside the global script context!) it may also be a good
opportunity to refactor and make clear what is intended to be
public API vs internal implementation details.
Speaking of, I took the librety to make `PLACEHOLDER`, `SEPARATOR`
and `I18nMissingInterpolationArgument` actual constants since it
seemed pretty clear to me those were just previously stashed on to
the `I18n` global to avoid polluting the global namespace, rather
than something we expect the consumers to set/replace.
2023-10-12 21:44:01 +08:00
|
|
|
"discourse-i18n",
|
2023-11-07 00:59:49 +08:00
|
|
|
"discourse-markdown-it",
|
2023-04-20 20:57:40 +08:00
|
|
|
"discourse-plugins",
|
|
|
|
|
"discourse-widget-hbs",
|
|
|
|
|
"ember-cli-progress-ci",
|
|
|
|
|
"ember-production-deprecations",
|
2023-10-02 18:36:06 +08:00
|
|
|
"float-kit",
|
2023-04-20 20:57:40 +08:00
|
|
|
"pretty-text",
|
|
|
|
|
"select-kit",
|
2023-10-02 18:36:06 +08:00
|
|
|
"theme-transpiler",
|
Enable Embroider/Webpack code spliting for Wizard (#24919)
(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>
2023-12-20 21:15:06 +08:00
|
|
|
"truth-helpers"
|
2023-04-20 20:57:40 +08:00
|
|
|
],
|
|
|
|
|
"resolutions": {
|
2024-01-11 01:30:50 +08:00
|
|
|
"**/unset-value": "2.0.1",
|
|
|
|
|
"**/ember-source": "3.28.12"
|
2023-04-20 20:57:40 +08:00
|
|
|
},
|
2023-05-03 16:25:13 +08:00
|
|
|
"devDependencies": {
|
2023-07-28 06:58:36 +08:00
|
|
|
"patch-package": "^8.0.0",
|
2023-04-20 20:57:40 +08:00
|
|
|
"postinstall-postinstall": "^2.1.0"
|
|
|
|
|
}
|
|
|
|
|
}
|