Update dev-infra's build-tooling since multiple ESM changes have
landed there. e.g. not relying on `require.main === module` for API
bundling. This will allow us to also execute all dev-infra rules
in ESM because we plan on applying our ESM patching to `ts_library`
(which would also affect build-tooling then).
PR Close#48521
We use `bazel/esbuild` in various places (e.g. for app bundling tests).
These tests rely on the Angular Compiler-CLI itself for e.g. linking
or the Terser configuration. Since everything in this repo is now
strict ESM, the ESBuild configs (which are already ESM-supported)
need to import from `//packages/compiler-cli`. We also need to be
able to leverage our existing ESM Bazel loader for this though as
otherwise resolution would fail.
Long-term we can remove this if everything in the compiler-cli
would use `.mjs` extensions and the import paths would also specify
an explicit extension. See: https://nodejs.org/api/esm.html#mandatory-file-extensions
PR Close#48521
The ESM loader when used with patched Bazel module resolution
handled subpaths incorrectly. e.g.
`@bazel/concatjs/tsc_wrapped/internal/index.js` could be incorrectly
resolved to `@bazel/concatjs/index.js`.
This commit fixes the flawed logic. Also we prioritize the ESM attempts
before the original specifier. This is necessary because otherwise
the default Node resolution (using `require.resolve`) may incorrectly
prefer the `index.js` file over a `index.mjs` when a directory is
imported.
PR Close#48521
RxJS currently ships ESM output that cannot be executed directly
in NodeJS. This is because RxJS ships ESM as `.js` files but does
not have a `package.json` which instructs Node to execute these as ESM.
RxJS would either need to use the explicit `.mjs` extension, or add
a `type: module` `package.json` next to the `.js` sources.
We manually patch RxJS to do this, while we wait on the upstream fix
to land. See: #7130.
PR Close#48521
The prodmode compilation pipeline -that we intend to use more heavily
now given it emitting files with the `.mjs` extension- exposes an
additional tsickle closure externs file. This file is empty most
of the time anyway since tsickle is not wired up.
We remove this generation as otherwise convenient `$(location` of
such ts library targets break because there always is more than 1 file.
PR Close#48521
We introduced a loader that supports ESM with Bazel. This loader can
only be enabled as part of our `nodejs_binary` defaults.bzl test. This
works fine, but there might be other binaries/tests e.g. from
`@angular/build-tooling` that should be able to use ESM & might need to
for importing the `compiler-cli`.
We move the logic for installing the patch into a `rules_nodejs` patch.
There is an existing one that is just updated to "enable ESM support".
PR Close#48521
This is necessary for e.g. JSON files from the CLDR data repository.
Otherwise these could not be added to the runfiles of the
binaries/tests.
PR Close#48521
For the ESM interop patches we expect to have two types
of patches:
* Patches for `node_modules`
* Patches for Bazel repositories.
We move the patches in respective folders to make it very clear
where a patch is used/applied to.
PR Close#48521
The Bazel NodeJS rules will always use the `.js` files as entry-points.
Since we only rely on the `.mjs` output going-forward, we need to teach
`nodejs_binary` and `nodejs_test` to use the `.mjs` extensions if
intended.
Our `defaults.bzl` macros will set `use_esm = True`, but other targets
from e.g. external repositories should keep the original behavior.
PR Close#48521
Replaces the existing ESM loader for dealing with external module
imports. This loader was introduced by Aspect for AIO `.mjs` scripts.
The loader will be used as foundation for a more extensive loader
that also properly handles first-party packages.
Additionally another loader is added, all packed as a single
loader because our current NodeJS version only supports a single
loader per node invocation. So we implement chaining ourselves.
The new loader will attempt rewriting `.js` extensions to `.mjs`,
also it will add `.mjs` if not already done. This is necessary
in the transition phase because we don't/cannot use explicit `.mts`
extensions and also we don't specify extensions in imports yet.
Long-term we would likely use `.mts` and explicit import extensions,
but it's not yet clear how we would sync this into g3 too.
PR Close#48521
This is in prearation for having a proper diff when this loader
is adjusted to support more situations than just simple external
node modules. See next commit.
Also the file is formatted to make the diff less verbose later.
The file was never formatted correctly and we don't lint `.mjs` files.
PR Close#48521
