Elgato_dark/angular
1
0
Fork 0
mirror of https://github.com/angular/angular synced 2026-05-24 09:28:37 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions
angular/packages/localize/package.json

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

46 lines
1.1 KiB
JSON
Raw Normal View History

feat(ivy): implement `$localize()` global function (#31609) PR Close #31609
2019-07-30 17:02:17 +00:00
{
"name": "@angular/localize",
"version": "0.0.0-PLACEHOLDER",
"description": "Angular - library for localizing messages",
feat(ivy): i18n - implement compile-time inlining (#32881) This commit implements a tool that will inline translations and generate a translated copy of a set of application files from a set of translation files. PR Close #32881
2019-10-08 13:46:28 +00:00
"bin": {
refactor: expose new `@angular/localize/tools` entry-point for CLI usage (#43431) This wires up the `@angular/localize/tools` entry-point. For context: This entry-point is being created to avoid deep imports into `@angular/localize/src/tools/<..>` like the CLI relies on. Deep imports do not play well with strict ESM, and now that all APF packages are strict ESM, the tool code needs to be either strict ESM as well. We use ESBuild to create individual bundles for the CLI entry-points, and the actual tool entry-point. We use a bundler because this enables the localize code be ESM compatible. Without a bundler, all relative imports within the `tools` entry-point would need to explicitly have the `.js` extension. This would be cumbersome and hard to maintain/enforce or validate. One might wonder why this is not a standard APF entry-point then. The answer is that the APF entry-points do not support exposing the CLI binaries (like `yarn localize-translate`). This could be done through tertiary entry-points, but using ESBuild directly gives us more control for now. We might want to revisit this in the future again. PR Close #43431
2021-09-24 17:19:11 +00:00
"localize-translate": "./tools/bundles/src/translate/cli.js",
"localize-extract": "./tools/bundles/src/extract/cli.js",
"localize-migrate": "./tools/bundles/src/migrate/cli.js"
},
"exports": {
"./tools": {
"types": "./tools/index.d.ts",
"default": "./tools/bundles/index.js"
}
feat(ivy): i18n - implement compile-time inlining (#32881) This commit implements a tool that will inline translations and generate a translated copy of a set of application files from a set of translation files. PR Close #32881
2019-10-08 13:46:28 +00:00
},
feat(ivy): implement `$localize()` global function (#31609) PR Close #31609
2019-07-30 17:02:17 +00:00
"author": "angular",
"license": "MIT",
feat(localize): update supported range of node versions (#41544) Update the supported range of node versions for Angular. Angular now supports node >=12.14.1 to <16.0.0, dropping support for Node v10. PR Close #41544
2021-04-12 19:12:51 +00:00
"engines": {
fix(core): update min Node.js support to 20.19, 22.12, and 24.0 (#61499) This is to match the versions of the Angular CLI. See: https://github.com/angular/angular-cli/pull/30349 PR Close #61499
2025-05-20 12:25:40 +00:00
"node": "^20.19.0 || ^22.12.0 || >=24.0.0"
feat(localize): update supported range of node versions (#41544) Update the supported range of node versions for Angular. Angular now supports node >=12.14.1 to <16.0.0, dropping support for Node v10. PR Close #41544
2021-04-12 19:12:51 +00:00
},
feat(ivy): implement `$localize()` global function (#31609) PR Close #31609
2019-07-30 17:02:17 +00:00
"repository": {
"type": "git",
"url": "https://github.com/angular/angular.git"
},
fix(ivy): missing schematics field in localize package (#33025) The schematics added in #32791 is currently failing as the package.json does not reference it. ``` > ng add @angular/localize@9.0.0-next.9 + @angular/localize@9.0.0-next.9 added 1 package from 1 contributor in 6.745s Installed packages for tooling via npm. The package that you are trying to add does not support schematics. You can try using a different version of the package or contact the package author to add ng-add support. ``` PR Close #33025
2019-10-07 10:06:16 +00:00
"schematics": "./schematics/collection.json",
feat(ivy): implement `$localize()` global function (#31609) PR Close #31609
2019-07-30 17:02:17 +00:00
"ng-update": {
"packageGroup": "NG_UPDATE_PACKAGE_GROUP"
},
fix(localize): install `@angular/localize` in `devDependencies` by default (#38680) Previously this package was installed in the default `dependencies` section of `package.json`, but this meant that its own dependencies are treated as dependencies of the main project: Babel, for example. Generally, $localize` is not used at runtime - it is compiled out by the translation tooling, so there is no need for it to be a full dependency. In fact, even if it is used at runtime, the package itself is only used at dev-time since the runtime bits will be bundled into a distributable. So putting this package in `devDependencies` would only prevent libraries from bringing the package into application projects that used them. This is probably good in itself, since it should be up to the downstream project to decide if it wants to include `@angular/localize` at runtime. This commit changes the default location of the package to be the `devDependencies` section, but gives an option `useAtRuntime` to choose otherwise. Fixes #38329 PR Close #38680
2020-09-02 15:16:10 +00:00
"ng-add": {
"save": "devDependencies"
},
feat(ivy): i18n - reorganize entry-points for better reuse (#32488) This is a refactoring that moves the source code around to provide a better platform for adding the compile-time inlining. 1. Move the global side-effect import from the primary entry-point to a secondary entry-point @angular/localize/init. This has two benefits: first it allows the top level entry-point to contain tree-shakable shareable code; second it gives the side-effect import more of an "action" oriented name, which indicates that importing it does something tangible 2. Move all the source code into the top src folder, and import the localize related functions into the localize/init/index.ts entry-point. This allows the different parts of the package to share code without a proliferation of secondary entry-points (i.e. localize/utils). 3. Avoid publicly exporting any utilities at this time - the only public API at this point are the global `$localize` function and the two runtime helpers `loadTranslations()` and `clearTranslations()`. This does not mean that we will not expose additional helpers for 3rd party tooling in the future, but it avoid us preemptively exposing something that we might want to change in the near future. Notes: It is not possible to have the `$localize` code in the same Bazel package as the rest of the code. If we did this, then the bundled `@angular/localize/init` entry-point code contains all of the helper code, even though most of it is not used. Equally it is not possible to have the `$localize` types (i.e. `LocalizeFn` and `TranslateFn`) defined in the `@angular/localize/init` entry-point because these types are needed for the runtime code, which is inside the primary entry-point. Importing them from `@angular/localize/init` would run the side-effect. The solution is to have a Bazel sub-package at `//packages/localize/src/localize` which contains these types and the `$localize` function implementation. The primary `//packages/localize` entry-point imports the types without any side-effect. The secondary `//packages/localize/init` entry-point imports the `$localize` function and attaches it to the global scope as a side-effect, without bringing with it all the other utility functions. BREAKING CHANGES: The entry-points have changed: * To attach the `$localize` function to the global scope import from `@angular/localize/init`. Previously it was `@angular/localize`. * To access the `loadTranslations()` and `clearTranslations()` functions, import from `@angular/localize`. Previously it was `@angular/localize/run_time`. PR Close #32488
2019-08-10 11:51:30 +00:00
"sideEffects": [
feat(bazel): (APF) Angular Package Format updates (#49559) Several updates to Angular Package Format. BREAKING CHANGE: Several changes to the Angular Package Format (APF) - Removal of FESM2015 - Replacing ES2020 with ES2022 - Replacing FESM2020 with FESM2022 PR Close #49559
2023-03-16 10:05:31 +00:00
"./fesm2022/init.mjs"
feat(ivy): i18n - reorganize entry-points for better reuse (#32488) This is a refactoring that moves the source code around to provide a better platform for adding the compile-time inlining. 1. Move the global side-effect import from the primary entry-point to a secondary entry-point @angular/localize/init. This has two benefits: first it allows the top level entry-point to contain tree-shakable shareable code; second it gives the side-effect import more of an "action" oriented name, which indicates that importing it does something tangible 2. Move all the source code into the top src folder, and import the localize related functions into the localize/init/index.ts entry-point. This allows the different parts of the package to share code without a proliferation of secondary entry-points (i.e. localize/utils). 3. Avoid publicly exporting any utilities at this time - the only public API at this point are the global `$localize` function and the two runtime helpers `loadTranslations()` and `clearTranslations()`. This does not mean that we will not expose additional helpers for 3rd party tooling in the future, but it avoid us preemptively exposing something that we might want to change in the near future. Notes: It is not possible to have the `$localize` code in the same Bazel package as the rest of the code. If we did this, then the bundled `@angular/localize/init` entry-point code contains all of the helper code, even though most of it is not used. Equally it is not possible to have the `$localize` types (i.e. `LocalizeFn` and `TranslateFn`) defined in the `@angular/localize/init` entry-point because these types are needed for the runtime code, which is inside the primary entry-point. Importing them from `@angular/localize/init` would run the side-effect. The solution is to have a Bazel sub-package at `//packages/localize/src/localize` which contains these types and the `$localize` function implementation. The primary `//packages/localize` entry-point imports the types without any side-effect. The secondary `//packages/localize/init` entry-point imports the `$localize` function and attaches it to the global scope as a side-effect, without bringing with it all the other utility functions. BREAKING CHANGES: The entry-points have changed: * To attach the `$localize` function to the global scope import from `@angular/localize/init`. Previously it was `@angular/localize`. * To access the `loadTranslations()` and `clearTranslations()` functions, import from `@angular/localize`. Previously it was `@angular/localize/run_time`. PR Close #32488
2019-08-10 11:51:30 +00:00
],
feat(ivy): i18n - implement compile-time inlining (#32881) This commit implements a tool that will inline translations and generate a translated copy of a set of application files from a set of translation files. PR Close #32881
2019-10-08 13:46:28 +00:00
"dependencies": {
build: update all non-major dependencies See associated pull request for more information.
2026-02-06 16:51:45 +00:00
"@babel/core": "7.29.0",
build: update babel dependencies (#53222) See associated pull request for more information. PR Close #53222
2024-01-31 21:04:56 +00:00
"@types/babel__core": "7.20.5",
refactor: replace `fast-glob` usage with `tinyglobby` (#60264) Usage of the `fast-glob` package has been replaced with the `tinyglobby` package. The change reduces the number of transitive dependencies related to these packages from 17 to 2 while also maintaining equivalent functionality. This was also changed in the Angular CLI packages. PR Close #60264
2025-03-07 09:31:06 +00:00
"tinyglobby": "^0.2.12",
build: update dependency yargs to v18 (#61767) See associated pull request for more information. PR Close #61767
2025-06-03 10:13:10 +00:00
"yargs": "^18.0.0"
build: set up all packages to publish via wombot proxy (#33747) PR Close #33747
2019-11-11 22:18:13 +00:00
},
refactor(localize): use the `FileSystem` from ngtsc (#36843) This commit makes the leap from its own custom baked `FileUtils` solution to the fully formed `FileSystem` that is used in the compiler-cli. This makes testing more straightforward and helps to ensure that the tool will work across operatings systems. Also, going forward, it will allow the localize project access to other useful code from the compiler-cli, such as source-map handling. PR Close #36843
2020-04-28 20:03:27 +00:00
"peerDependencies": {
"@angular/compiler": "0.0.0-PLACEHOLDER",
"@angular/compiler-cli": "0.0.0-PLACEHOLDER"
feat(ivy): implement `$localize()` global function (#31609) PR Close #31609
2019-07-30 17:02:17 +00:00
}
fix(localize): install `@angular/localize` in `devDependencies` by default (#38680) Previously this package was installed in the default `dependencies` section of `package.json`, but this meant that its own dependencies are treated as dependencies of the main project: Babel, for example. Generally, $localize` is not used at runtime - it is compiled out by the translation tooling, so there is no need for it to be a full dependency. In fact, even if it is used at runtime, the package itself is only used at dev-time since the runtime bits will be bundled into a distributable. So putting this package in `devDependencies` would only prevent libraries from bringing the package into application projects that used them. This is probably good in itself, since it should be up to the downstream project to decide if it wants to include `@angular/localize` at runtime. This commit changes the default location of the package to be the `devDependencies` section, but gives an option `useAtRuntime` to choose otherwise. Fixes #38329 PR Close #38680
2020-09-02 15:16:10 +00:00
}
Reference in a new issue Copy permalink