We are dropping the custom ESBuild and Terser pipeline from dev-infra
and instead leverage the Angular CLI directly. This commit adjusts
the benchmarks to use this new rule.
PR Close#61566
Instead of dev-infra maintaining a custom ESBuild + Terser pipeline that
tries to emulate the Angular CLI, we are switching the bundling core
tests to a new rule that really leverages the Angular CLI.
This involves some file renames and small adjustments. In addition, we
leverage the updated symbol tracking rule to output new goldens that can
work with multiple bundle files (as generated by the Angular CLI;
especially with defer and its "lazy" chunks).
PR Close#61566
Since we are going to replace our `app_bundle` rule (custom ESBuild +
Terser pipeline) with the real Angular CLI where shared/lazy/common
chunks may exist, we need to update the symbol extractor to support
multiple files.
We could have just merged all symbols, but this commit tries to do
better by detecting what symbols are loaded eagerly vs. lazily. This
will be very useful for e.g. defer tests or other lazy features we are
introducing in the feature.
PR Close#61566
The `app_bundle` rule does not work after the migration of
`packages/compiler` to `ts_project` because the `.mjs` extensions are
now missing in the non npm-package output.
This causes runtime errors as `.js` is not recognized as ESM. Switching
to the real npm package for usage, fixes this issue.
PR Close#61566
Currently when linking the `@angular/compiler-cli` package, the peer
dependency to `compiler` is not resolved and we are trying to make the
compiler dependency available via `data`. This is unidiomatic and
brittle. This commit fixes this.
PR Close#61566
Compiler now would have `.js` files. Those aren't picked up as ESM,
unless we install the `package.json` with `type: module`. Sounds great
on paper, but doesn't work in reality because the way the compiler
packages are available to `api-gen/` is via the old `rules_nodejs`
linker, so the `packages/package.json` wouldn't work; nor do the
`package.json`s of the e.g. compiler-cli package work- because those
already contain the `exports` of the built npm package.
We fix this in a much more reasonable way, and the whole module
resolution problem by leveraging the pnpm linking here. This works as
expected.
PR Close#61566
Removes the following unused code from the compiler:
* The ICU expander appears to be some really old code converting ICUs into legacy-style control flow directives. It's annoying to keep this one since we need to update it any time the AST changes.
* The `PipeCollector` class wasn't used anywhere.
* The `partitionArray` function wasn't used anywhere.
* The `newArray` function was used only in one test and it can be easily replaced with `new Array().fill`.
PR Close#61668
In this commit, we switch from using the `isPlatformServer` runtime call to the `ngServerMode`.
Note: constructors haven't been touched in order to prevent any breaking changes for the public API.
PR Close#59496
Replaces the `propertyInterpolateX` instructions with calls to `property` and the `interpolate` helper. This allows us to drop the dedicated interpolation instructions and simplify the runtime for future work.
PR Close#61639
Updates the `ɵɵinterpolate` instruction so it doesn't call into `interpolation1` under the hood since it requires a prefix/suffix and we know there isn't one.
PR Close#61639
Replaces the `classMapInterpolateX` instructions with `classMap` plus a call to `interpolate` in order to simplify the runtime. The only difference between `classMapInterpolateX` and `classMap` was that the former passes `keyValueArraySet` into `checkStylingMap` while the latter passes `classKeyValueArraySet`. This doesn't appear to matter, because the interpolation instructions always have a string value which means that the function is never called.
PR Close#61639
Replaces the `styleMapInterpolateX` instructions with the existing `styleMap` and a passed-in interpolated value in order to simplify the runtime.
PR Close#61639
The hardcoded config was introduced because suppressing the diagnostic
via `extendedDiagnostics` in the TS config was unreliable in google3.
This has since been fixed and the workaround is no longer needed.
PR Close#61622
Matthieu Riegler