For the `rules_js` migration, we are facing the problem where
our current Angular code is shipped as ESM, but we aren't fully
there yet with fully compliant strict ESM during development.
That is because we lack explicit import extensions, and it's also a
different story how this would work in Google3, if we were to add them.
In addition, we cross-import from our packages using npm module names.
This works well for TS, for ESBuild because those can respect path
mappings— but at runtime, when executing native `jasmine_test`'s— such
mappings aren't respected. The options here are:
- avoid module imports in the repo (impossible; undesired)
- use pre-bundling of all NodeJS execution involving npm package code
(slower, extra build action cost)
- wire up a simple NodeJS loader (supported via official APIs) to simply
account for our cases (preferred and similar to what we experimented
with for the last year(s); and worked well)
This commit implements the last option and allows for an easy migration
to `rules_js`, and also is pretty reasonable. Long-term we can resolve
the extension problem if we e.g. migrate to real explicit extensions + a
proper TS module resolution like e.g. `nodenext`.
PR Close#61895
This commit migrates the remaining pieces of `compiler-cli` to
`ts_project`. This involves a few more things during migration:
- the `ng_module` ngc_wrapped rule broke as part of this change, so we
switched it to `ts_project` too. This logic is soon gone anyway.
- we needed an extra pnpm "package.json" for the linker babel test. This test is
loading from the real compiler-cli npm package. Babel needs a real
node module for this, so this solution seems reasonable. It may be
worth exploring in the future to move this test into an integration
test though.
- the older integrationtest in compiler-cli is removed as the coverage
is much better with the compliance test suite and this test.
PR Close#61862
This ensures that the new optimization rule, and also adev (when we
complete migrating it to `rules_js`) can use the latest compiler-cli
version from HEAD.
PR Close#61810
PR Close#61830
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.
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).
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.
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.
Angular Robot