github-mirror/discourse
github-mirror/discourse
2
0
Fork 0
mirror of https://github.com/discourse/discourse.git synced 2025-02-23 15:57:41 +08:00
Code Issues Actions 1 Packages Projects Releases Wiki Activity
discourse/app/assets/javascripts/discourse-i18n/package.json

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

39 lines
727 B
JSON
Raw Normal View History

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 06:44:01 -07:00
{
"name": "discourse-i18n",
"version": "1.0.0",
"private": true,
"description": "Discourse's i18n",
"author": "Discourse <team@discourse.org>",
"license": "GPL-2.0-only",
"keywords": [
"ember-addon"
],
"exports": {
".": "./src/index.js",
"./addon-main.js": "./addon-main.cjs"
},
"files": [
"addon-main.cjs",
"src"
],
"dependencies": {
DEV: Upgrade the MessageFormat library (JS) This patch upgrades the MessageFormat library to version 3.3.0 from 0.1.5. Our `I18n.messageFormat` method signature is unchanged, and now uses the new API under the hood. We don’t need dedicated locale files for handling pluralization rules anymore as everything is now included by the library itself. The compilation of the messages now happens through our `messageformat-wrapper` gem. It then outputs an ES module that includes all its needed dependencies. Most of the changes happen in `JsLocaleHelper` and in the `ExtraLocales` controller. A new method called `.output_MF` has been introduced in `JsLocaleHelper`. It handles all the fetching, compiling and transpiling to generate the proper MF messages in JS. Overrides and fallbacks are also handled directly in this method. The other main change is that now the MF translations are served through the `ExtraLocales` controller instead of being statically compiled in a JS file, then having to patch the messages using overrides and fallbacks. Now the MF translations are just another bundle that is created on the fly and cached by the client.
2024-06-17 18:21:04 +02:00
"@embroider/addon-shim": "^1.8.9",
"make-plural": "^7.4.0"
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 06:44:01 -07:00
},
"engines": {
DEV: Update ember-cli to 5.6.0 (#25886)
2024-02-27 10:48:30 +01:00
"node": ">= 18",
DEV: Switch to pnpm for JS dependencies (#28671) This will bring significant improvements to install speed & storage requirements. For information on how it may affect you, see https://meta.discourse.org/t/324521 This commit: - removes the `yarn.lock` and replaces with `pnpm-lock.yaml` - updates workspaces to pnpm format - adjusts package dependencies to work with pnpm's stricter resolution strategy - updates Rails app to load modules from more specific node_modules directories - adds a `.pnpmfile` which automatically cleans up old yarn-managed `node_modules` directories - updates various scripts to call `pnpm` instead of `yarn` - updates patches to use pnpm's native patch system instead of patch-package - adds a patch for licensee to support pnpm
2024-09-03 10:51:07 +01:00
"npm": "please-use-pnpm",
"yarn": "please-use-pnpm",
"pnpm": ">= 9"
DEV: Reformat package.json files (#28733)
2024-09-04 21:14:13 +02:00
},
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 06:44:01 -07:00
"ember": {
"edition": "octane"
},
"ember-addon": {
"version": 2,
"type": "addon",
"main": "addon-main.cjs",
"app-js": {}
}
}
Reference in New Issue Copy Permalink