Commit graph

14 commits

Author SHA1 Message Date
Joey Perrott
557ac51c32 build: migrate to using new jasmine_test (#62131)
Migrate additional targets to jasmine_test

PR Close #62131
2025-06-19 10:06:27 +02:00
Joey Perrott
3a0cfd544d build: migrate to using new jasmine_test (#62086)
Use the new jasmine_test based on rules_js instead of jasmine_node_test from rules_nodejs

PR Close #62086
2025-06-18 08:27:26 +02:00
Paul Gschwendtner
a137746110 build: migrate packages/core/test to new jasmine_test rule (#61902)
Migrates `packages/core/test` to the new `jasmine_test` rule. As part of
this, we are also removing an unnecessary/unused test fixture.

PR Close #61902
2025-06-12 10:00:09 +02:00
Paul Gschwendtner
c706525a33 build: update node loader to support zone.js (#61902)
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
2025-06-12 10:00:09 +02:00
Paul Gschwendtner
08b543e2f6 build: add jasmine_test macro for replacing jasmine_node_test legacy rule (#61902)
This commit introduces the new `jasmine_test` macro that can be an
"almost" drop-in replacement for `jasmine_test`.

PR Close #61902
2025-06-12 10:00:09 +02:00
Paul Gschwendtner
df0b8d45da build: add small comment for ng_package_link_interop.bzl (#61902)
This should make the intent a little more clearer if someone
just looks at this file.

PR Close #61902
2025-06-12 10:00:09 +02:00
Paul Gschwendtner
d86d11d4c1 build: introduce NodeJS loader for rules_js Node execution (#61865)
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
2025-06-05 12:04:51 +02:00
Paul Gschwendtner
d081ef9b06 build: replace all ng_package with new rule from rules_angular (#61843)
Replaces all `ng_package` rule with the new rule from `rules_angular`.

PR Close #61843
2025-06-04 09:13:41 +00:00
Paul Gschwendtner
579618d6d6 build: remove packages/bazel (#61843)
Removes the `@angular/bazel` package as we no longer need it. Yay!

It's replaced by `rules_angular`.

PR Close #61843
2025-06-04 09:13:41 +00:00
Paul Gschwendtner
925b923e85 build: add modified version of tsec that can work with interop (#61275)
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
2025-05-14 12:01:51 +00:00
Paul Gschwendtner
c123125ca1 build: fix ts_project interop to properly create linker mappings (#61275)
This commit fixes that the interop targets weren't properly creating
linker mappings in some cases. This could break spec bundling.

PR Close #61275
2025-05-14 12:01:51 +00:00
Paul Gschwendtner
397f9987ef build: support new ng_project rule (#61275)
Supports the `ng_project` rule with the local compiler-cli version
from HEAD.

PR Close #61275
2025-05-14 12:01:51 +00:00
Paul Gschwendtner
a1bf58e32e build: migrate symbol-extractor to ts_project (#61156)
Migrates the symbol-extractor code to `ts_project`.

PR Close #61156
2025-05-07 11:28:59 -07:00
Joey Perrott
72b7de0d73 build: set up ts_project interop for rules_js migration (#61087)
The `ts_project` interop rule that we've built was also used in the
Angular CLI migration, and it allows us to mix `ts_project` and
`ts_library` targets; enabling an incremental migration. Additionally
set up the `ng_project` to replace `ng_module`.

PR Close #61087
2025-05-02 09:12:23 -07:00