Use the packaged versions of the packages instead of the local ts_project dependencies to prevent multiple versions of the deps to enter test bundles
PR Close#62413
Use the packaged versions of the packages instead of the local ts_project dependencies to prevent multiple versions of the deps to enter test bundles
PR Close#62413
Temporarily updates the new Node loader to work with `zone.js` `.mjs`
files that are still ending up at runtime due to this package using
`ts_library`.
PR Close#61902
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#61865
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#61826
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
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
Disables creation of the esbuild meta.json file, which is not utilized in the build process. This streamlines the output and avoids generating unused artifacts.
PR Close#61636
Use an unstamped version of the compiler when it runs in `ng_project` as it will get stamped appropriately
whenever the generated code gets stamped after its usage."
PR Close#61479
* Fixes that the symbol extractor approval script was broken after some recent build changes.
* Fixes the `run_all_symbol_extractor_tests` script which wasn't resolving any targets, because the rule name changed.
PR Close#61407
Migrates `packages/core/schematics` to `ts_project`. As part of this,
this commit cleans up some of the mixed module types and tsconfigs in
the folder. A single tsconfig (and it's test variant) are now used.
For the shipped schematics, we explicitly use the `.cjs` extension, so
that the bundles are properly recognized as CommonJS; even if they are
part of the `type: module` `@angular/core` package.
The `package.json` with `type: commonjs` is removed from
`packages/core/schematics` as it's no longer needed given the explicit
extension & caused issues as schematics are compiled with ESM but are
only later bundled for shipping & some tests as ESM.
PR Close#61370
As we migrate more and more code to `ts_project`, we are ending up with
`.js` file extensions (ts_library did generate `.mjs` magically).
Since we don't want to get into the business of migrating
`nodejs_binary` targets at this point (in some cases we might)— we
should support pointing to such files.
PR Close#61370
As we roll out more PRs that migrate to `ts_project`, we need to make
sure that we don't break existing `tsec` targets. This PR copies the
original `tsec` Starlark code and adjusts it to work with the interop.
Note that we don't patch as this would unnecessarily complicate this
file that only exists during migration. Long-term, after migration, we
either need to consider switching to the new ESLint plugin that is being
worked on (I'm in contact with the team), or we send a CL to update the
Tsec Starlark code to keep our changes minimal and avoid scope increase.
PR Close#61275
Joey Perrott