The `@babel/core` package provides the functionality of multiple other babel packages
without the need to directly depend or import the other babel packages. Since the
`@babel/core` package is already used and imported in the locations that previously
used the other babel packages, an overall reduction in both imports and dependencies
is possible. Six babel related packages were able to be removed from the root `package.json`
and one (also present in the aforementioned six) was removed as a dependency from the
`@angular/localize` package. Unfortunately, the functionality used from the `@babel/generator`
package is not provided by `@babel/core` and is still present. Further refactoring may
allow its removal as well in the future.
The following packages were removed:
* @babel/parser
* @babel/template
* @babel/traverse
* @babel/types
* @types/babel__template
* @types/babel__traverse
PR Close#53441
The `@babel/core` package provides the functionality of multiple other babel packages
without the need to directly depend or import the other babel packages. Since the
`@babel/core` package is already used and imported in the locations that previously
used the other babel packages, an overall reduction in both imports and dependencies
is possible. Six babel related packages were able to be removed from the root `package.json`
and one (also present in the aforementioned six) was removed as a dependency from the
`@angular/localize` package. Unfortunately, the functionality used from the `@babel/generator`
package is not provided by `@babel/core` and is still present. Further refactoring may
allow its removal as well in the future.
The following packages were removed:
* @babel/parser
* @babel/template
* @babel/traverse
* @babel/types
* @types/babel__template
* @types/babel__traverse
PR Close#53374
Switches the syntax for blocks from `{#block}{/block}` to `@block {}` based on the feedback from the community.
Read more about the decision-making process in our blog: https://blog.angular.io/meet-angulars-new-control-flow-a02c6eee7843
The existing block types changed in the following ways:
**Conditional blocks:**
```html
<!-- Before -->
{#if cond}
Main content
{:else if otherCond}
Else if content
{:else}
Else content
{/if}
<!-- After -->
@if (cond) {
Main content
} @else if (otherCond) {
Else if content
} @else {
Else content
}
```
**Deferred blocks**
```html
<!-- Before -->
{#defer when isLoaded}
Main content
{:loading} Loading...
{:placeholder} <icon>pending</icon>
{:error} Failed to load
{/defer}
<!-- After -->
@defer (when isLoaded) {
Main content
} @loading {
Loading...
} @placeholder {
<icon>pending</icon>
} @error {
Failed to load
}
```
**Switch blocks:**
```html
<!-- Before -->
{#switch value}
{:case 1}
One
{:case 2}
Two
{:default}
Default
{/switch}
<!-- After -->
@switch (value) {
@case (1) {
One
}
@case (2) {
Two
}
@default {
Default
}
}
```
**For loops**
```html
<!-- Before -->
{#for item of items; track item}
{{item.name}}
{:empty} No items
{/for}
<!-- After -->
@for (item of items; track item) {
{{item.name}}
} @empty {
No items
}
```
PR Close#51891
Currently internally Angular has some customized tsconfig files, because we don't align with the tsconfig of the rest of g3. These changes enable `noImplicitReturns` and `noPropertyAccessFromIndexSignature` to align better with the internal config.
PR Close#51728
⚠️Disclaimer⚠️ this PR implements syntax that is still in an open RFC. It will be adjusted once the RFC is closed.
These changes implement the `BlockGroup` and `Block` AST nodes that will then be used to generate instructions based on the new syntax. A `BlockGroup` is a container for `Block` instances. The first block of a block is always implicit and required while any subsequent blocks are optional.
PR Close#50953
Update Glob to fast-glob to remove the dependence of Inflight that contains a memory leak
Signed-off-by: Kevin Gay <5970002+GayKevin@users.noreply.github.com>
PR Close#50632
The `packages/localize` package still required some trickery
to support CommonJS because tests in the repo were running as CommonJS.
This commit removes the CommonJS logic in localize and its tests, so
that only ESM is used in production & tests.
PR Close#48521
This change removed the deprecated `canParse` method from all the TranslationParsers.
BREAKING CHANGE:
- `canParse` method has been removed from all translation parsers in `@angular/localize/tools`. `analyze` should be used instead.
- the `hint` parameter in the`parse` methods is now mandatory.
PR Close#47275
We recently updated Babel and the Bazel types but this actually
resulted in duplicates, causing differences between what people
seen in their IDE vs. what Bazel builds.
This commit removes the lock file and generates it fully fresh,
deduping dependencies and also fixing the differences between
local IDE and Bazel.
As part of this we also need to update/fixup one assertion on the
Babel node path types, because the node start/end can now also
be `undefined`.
PR Close#45967
This commit addresses two issues:
* The init entry-point currenly access code from another entry-point
using relative imports, resulting in code to be duplicated.
* The init types are now bundled as part of the ng_package APF rule.
There is an API extractor bundling issue with global module
augmentations.
API extractor does not properly handle module augmentation. We need to disable
dts bundling for this entry-point to ensure `$localize` remains globally accessible
for users. This is an option in the `ng_package` rule.
Note that this worked before because `localize/init` was a `ts_library` that did not
have its types bundled.
As part of this change, the `MessageId` and `TargetMessage` exports are
also made public. The localize exported functions rely on these types but
they were not exported.
Related to types, an exception is added for three private exports from the primary
entry-point so that they will show up in the API golden. These private
exports are re-exposed publicly in the init entry-point but no golden
would capture them due to the private symbol prefix. One might wonder
why the symbols are not guarded in the init golden. The reason is that
goldens never inline signatures from cross-entry-points/packages to avoid
duplication.
Lastly, the i18n integration test golden had to be updated because the
polyfills bundle increased slightly. After thorough and time-consuming
investigation, this mostly happens due to different mangle identifies
being used (the input code changed --> so the mangling determinism)
Size before this change:
```
SUCCESS: Commit undefined uncompressed runtime did NOT cross size threshold of 500 bytes or >1% (expected: 929, actual: 926).
SUCCESS: Commit undefined uncompressed main did NOT cross size threshold of 500 bytes or >1% (expected: 124544, actual: 124660).
SUCCESS: Commit undefined uncompressed polyfills did NOT cross size threshold of 500 bytes or >1% (expected: 34530, actual: 34641).
```
After:
```
SUCCESS: Commit undefined uncompressed runtime did NOT cross size threshold of 500 bytes or >1% (expected: 929, actual: 926).
SUCCESS: Commit undefined uncompressed main did NOT cross size threshold of 500 bytes or >1% (expected: 124544, actual: 124650).
FAIL: Commit undefined uncompressed polyfills exceeded expected size by 500 bytes or >1% (expected: 34530, actual: 35252).
```
Inspecting/comparing without mangling shows that the new changes would
actually result in a bundle reduction (potentially visible with
gzip/brotli):
```
➜ Desktop stat -f%z master-nomangle.js
101357
➜ Desktop stat -f%z with-changes-nomangle.js
101226
```
PR Close#45405
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
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
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
