Commit graph

3 commits

Author SHA1 Message Date
Joey Perrott
c35c0c7f2f build: update to bazel 7.6.0 (#63096)
Update to later version of bazel

PR Close #63096
2025-08-14 13:01:30 +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
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