Node.js v12 will become EOL on 2022-04-30. As a result, Angular CLI v14 will no longer support Node.js v12.
BREAKING CHANGE:
Support for Node.js v12 has been removed as it will become EOL on 2022-04-30. Please use Node.js v14.15 or later.
PR Close#45286
The `@angular/localize` package depends on a version of Babel that is two years
old, so this commit updates to the latest version.
Some changes were made to the linker and compliance tests to account for slight
changes in source maps, along with a few code updates because of changes to
the typings of Babel.
PR Close#44931
The compiler-cli's declaration files are not necessarily compatible with web
environments that use `@angular/localize`, and would inadvertently include
`typescript` declaration files in any compilation unit that uses
`@angular/localize` (which increases parsing time and memory usage during
builds) using a default import that only type-checks when
`allowSyntheticDefaultImports` is enabled.
Fixes#45179
PR Close#45180
To make our test output i.e. devmode output more aligned
with what we produce in the NPM packages, or to be more
aligned with what Angular applications will usually consume,
the devmode output is switched from ES5 to ES2015.
Additionally various tsconfigs (outside of Bazel) have been
updated to match with the other parts of the build. The rules
are:
ES2015 for test configurations, ES2020 for actual code that will
end up being shipped (this includes the IDE-only tsconfigs).
PR Close#44505
The schematic code in `@angular/localize` is currently still emitted
as CommonJS, while the rest of `@angular/localize` is strict ESM (which
is also denoted through `type: module` in the package.json file).
The schematic code is currently imported as CJS from the CLI so it
is not a problem right now. Still, it is safer to ensure the code
for schematics is properly picked up as CJS through a local
`package.json` file resetting `type: module` to `type: commonjs`.
PR Close#44016
Enables code spitting for ESBuild bundling of the localize/tools entry
point. When we initially configured ESBuild as part of APF v13, we left
this option disabled as code splitting is marked experimental. The ESM
splitting mechanism in ESBuild seems very solid so far (judging subjectively
and by experience/reports in the ESBuild repo), so we should give it a shot,
in order to significantly reduce the size of the NPM package, and simplify
debugging (by not having duplicated code portions for all the different entry points).
To clarify: Code splitting is helpful as we have multiple entry-points
that currently duplicate code. With code splitting these entry-points
would share common code instead.
PR Close#43932
When extracting i18n messages, the Angular compiler needs to split ICU expressions
into their own message. Currently there is no guaranteed way to re-associate
the ICU message with the original message where the ICU was found.
This change adds support in the localize tooling so that associated ids can be
stored as metadata in the `$localize` tagged strings. These ids can then be
used in generated translation files to provide a link between the two messages.
The XLIFF 1.2 and 2.0 formats have been updated to render these relationships,
via the `xid` and `subFlows` attributes respectively.
PR Close#43534
This commit updates the `node` engines range for all Angular
framework packages to:
* No longer support NodeJS v12 `< 12.20`. This is done because APF v13
uses package export patterns which are only supported as of v12.20.
https://nodejs.org/api/packages.html#packages_subpath_patterns.
* Allows for the latest v16 NodeJS versions. This matches with the CLI
which added NodeJS v16 support with https://github.com/angular/angular-cli/pull/21854.
We already limit this to `>= v16.10.0` in preparation to only
supporting the LTS minors of Node v16.
BREAKING CHANGE: NodeJS versions older than `v12.20.0` are no longer
supported due to the Angular packages using the NodeJS package exports
feature with subpath patterns.
PR Close#43740
This commits sets the JS target for all command line tools to
NodeJS v12. ESbuild will automatically downlevel the ES2020 features
we currently use to make them compatible with NodeJS v12 <-> ES2019.
ES2020 is the prodmode output, but we still support Node v12 so
there needs to be some downleveling for now.
Note: This is a separate commit because initially the target was
set to Node v14 to match up with the prodmode Bazel output.
PR Close#43431
Given that we ship all of compiler-cli and localize in ESM
mode now, we need to use a ESM compatible version of Yargs.
The latest version seems ESM compatible but with some small
API changes. This commit updates Yargs and updates the command
line option code to use the new API.
PR Close#43431
As outlined in the previous commit which enabled the `esModuleInterop`
TypeScript compiler option, we need to update all namespace imports
for `typescript` to default imports. This is needed to allow for
TypeScript to be imported at runtime from an ES module.
Similar changes are needed for modules like `semver` where the types incorrectly
suggest named exports that will not exist at runtime when imported from ESM.
This commit refactors all imports to match with the lint rule we have
configured in the previous commit. See the previous commit for more
details on why certain imports have been changed.
A special case are the imports to `@babel/core` and `@babel/types`. For
these a special interop is needed as both default imports, or named
imports break the other module format. e.g default imports would work
well for ESM, but it breaks for CJS. For CJS, the named imports would
only work, but in ESM, only the default export exist. We work around
this for now until the devmode is using ESM as well (which would be
consistent with prodmode and gives us more valuable test results). More
details on the interop can be found in the `babel_core.ts` files (two
interops are needed for both localize/or the compiler-cli).
PR Close#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
Moves the `src/tools` folder of the `@angular/localize` package into the
top-level of the package. This is in preparation of actually exposing an
entry-point for the tools that can be accessed using
`@angular/localize/tools`.
We want to expose such an entry-point because the CLI currently
deep-imports into various places of the tools, but this will not
work well with strict ESM because the localize tool depends on the
v13 strict ESM packages like the `@angular/compiler` or
`@angular/compiler-cli`.
PR Close#43431
Updates the `sideeEffects` field in `package.json` files to reflect the
new APF v13 format where files use the `.mjs` extension, and are located
in new directories (like the `fesm2020` folder).
PR Close#43431
The Angular Core and localize package currently use deep imports for
code that is shipped. This is problematic as we want to ship the
compiler-cli as full-ESM. To achieve this we need to use a bundler and
this breaks deep imports.
We use a bundler for the compiler CLI because for full ESM
compatibility, we would need to explicitly add the `.js` extension
to all relative imports. This is very cumbersome and prone to mistakes
so to mitigate this problem in a safe way, we bundle the compiler-cli.
Note: Deep imports continue to exist for the language service as it
bundles the compiler-cli.
PR Close#43431
With the changes to support APF v13 in the `ng_package` rule, we have
removed the ambiguous `entry_point` attribute. The attribute suggested
that it would be used for determining the primary entry-point input
file. This was not the case as the flat module output file is consulted
for bundling et at. The attribute has been renamed to match its
purposed (renamed to `primary_bundle_name`).
We no longer need to set that attribute because the primary bundle
name is (1) not of relevance for consumers and (2) the rule already
infers the bundle name properly from the Bazel package.
PR Close#43431
Updates the Bazel NodeJS rules to v4.0.0-beta.0. This is necessary
so that the Angular components repo can update, and it's generally
good to stay as up-to-date as possible with the Bazel rules as it's
easy to fall behind, and updating early allows us to discover issues
affecting our tooling earlier (where they are easier to address due to
e.g. potential breaking change policy).
PR Close#42760
Previously, we used custom typings for the ServiceWorker environment.
This was necessary back when the ServiceWorker package was introduced,
since there were no official typings.
Since there are now official typings for Web Workers (including
ServiceWorkers) offered by TypeScript as [lib.webworker.d.ts][1], this
commit gets rid of our custom typings in favor of using the official
ones.
[1]: https://github.com/microsoft/TypeScript/blob/v4.3.4/lib/lib.webworker.d.ts
PR Close#42736
For quite a while it is an unspoken convention to add a trailing
new-line files within the Angular repository. This was never enforced
automatically, but has been frequently raised in pull requests through
manual review. This commit sets up a lint rule so that this is
"officially" enforced and doesn't require manual review.
PR Close#42478
Update the supported range of node versions for to be less restrictive, no longer causing
yarn or npm to fail engine's checks for future versions of node.
While this change will no longer cause yarn or npm to fail these engine's check, this does
not reflect a change in the officially supported versions of node for Angular. Angular
continues to maintain support for Active LTS and Maintenance LTS versions of node.
PR Close#42205
Remove publishConfig property from the package.json entry for each of the entries in
the publish configuration. Using the wombat proxy is now ensured/managed by the
ng-dev release tooling.
PR Close#42104
Some localization workflows want to use the extracted source translation
files directy back in the project as a target translation file.
The extraction process generates files that only contain "source" messages
and not "target" messages. This is actually valid for most translation formats
but currently the Angular localization process expects target translation files
to always contain target messages and will stop with an error in this case.
Now, instead of an error, the translation file loader will log a warning,
and then try to falback to a source message, only erroring if this is also
missing.
Fixes#21690
PR Close#41944
The ViewEngine message extraction would trim the values
of the `equiv-text` attributes. This commit aligns the Ivy
extraction of these attributes.
Fixes#41176
PR Close#41180
When there are elements in a translated message, the start and end tags
are encoded as placeholders. The names of these placeholders are computed
from the name of the element. For example `<a> will be `START_LINK` and
`</a>` will be `CLOSE_LINK`.
If there are more than one element with the same name, but different attributes,
then the starting placeholder name is made unique.
For example `<a href="a">` would be `START_LINK`, while `<a href="b">` in
the same message would then be called `START_LINK_1`.
But the closing tags will not be made unique since there are no attrbutes;
the always have the same text `</a>`, which will produce, for example,
`CLOSE_LINK`.
Previously, when extracting XLIFF 2 formatted translation files, the closing
tag placeholder names were computed incorrectly from the opening tag
placeholder names. For example `CLOSE_LINK_1`.
This commit strips these `_1` type endings from the start tag placeholder
name when computing the closing tag placeholder name. It also ensures
that the `type` of the placeholder is computed accurately in these cases
too.
Fixes#41142
PR Close#41152
Adds a new flag to `localize-extract` called `--migrateMapFile` which will generate a JSON file
that can be used to map legacy message IDs to cannonical ones.
Also includes a new script called `localize-migrate` that can take the mapping file which was
generated by `localize-extract` and migrate all of the IDs in the files that were passed in.
PR Close#41026
These tests were relying upon unix-like paths, which
caused them to fail on Windows.
Note that the `filegroup` Bazel rule tends not to work well
on Windows, so this has been replaced with `copy_to_bin`
instead.
PR Close#40952
With this change we drop support for zone.js 0.10.x.
This is needed because in version 12 the CLI will only work with `~0.11.4`. See angular/angular-cli#20034.
BREAKING CHANGE:
Minimum supported `zone.js` version is `0.11.4`
PR Close#40823
Previously we were calling `updateSourceLocations()` as part of
`extractMessages()` for every file that was passed in, regardless of
whether any `$localize` tagged strings were to be found in the file.
This was very wasteful because it is non-trivial to compute the flattened
source-map for files if it is not needed.
PR Close#40891
When the downleveling helper function has been inlined into the
`$localize` call, it is a bit more tricky to parse out the cooked and
raw strings. There was already code to do this but it assumed that
the `cooked` and `raw` items were both arrays.
Sometimes the `raw` array is just a copy of the `cooked` array
via an expression similar to `raw || (raw=tcookedslice(0))`. This
commit changes the `unwrapMessagePartsFromLocalizeCall()`
function to be able to handle such a situation.
Fixes#40702
PR Close#40754
Previously if the code is invalid the error message might look like:
```
Unexpected messageParts for `$localize` (expected an array of strings).
```
This is not very helpful for debugging where the problem occurs.
Now we build a "code-frame" description to give more useful information:
```
TypeError: Cannot create property 'message' on string '.../src/app/app.component.js:
Unexpected messageParts for `$localize` (expected an array of strings).
4 | export class AppComponent {
5 | constructor() {
> 6 | this.title = $localize(a = ['myapp'], []);
| ^^^^^^^^^^^^^
7 | }
8 | }
```
PR Close#40724
The ARB format doesn't have a dedicated field for message meaning so these changes include it
as a customize attribute called `x-meaning`.
Fixes#40506.
PR Close#40546
