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
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
This change aligns with the supported Node.js versions of the Angular CLI.
See: https://github.com/angular/angular-cli/pull/24026
BREAKING CHANGE: Angular no longer supports Node.js versions `14.[15-19].x` and `16.[10-12].x`. Current supported versions of Node.js are `14.20.x`, `16.13.x` and `18.10.x`.
PR Close#47730
The dev-infra build tooling is now decoupled from `ng-dev`. This will
make it easier to update `ng-dev` without necessarily needing to upgrade
the whole build system, Bazel etc. This is useful when e.g. new release
tool features have been added and should also be ported to active LTS
branches.
PR Close#46976
The integration test rule now always executes tests in a directory
outside of the execroot. This ensures a more hermetic test environment
on platforms without a sandbox, or when tests are run with `tags:
local`.
As part of this change, an issue with Yarn 1.x. and `nodejs_binary`
unveiled. Yarn 1.x. is resolved properly using the tool mapping but
when Yarn inside Yarn is invoked (e.g. using `package.json` scripts),
then the second nested Yarn invocation fails due to an unknown path.
This happens because Yarn in the original invocation creates another
directory in the `/tmp` directory and modifies the `PATH` so that
the same `yarn` can be invoked again. This makes sense conceptually
but breaks in our case because the Yarn Bash script put into the `/tmp`
directory tries to resolve our vendored Yarn script relatively (which
is the wrong spot here). It worked previously in the execroot because
`nodejs_binary` invoked Yarn through `<external>/../node.sh
<absolute-path-to-yarn-cjs-script>`, but outside the execroot it invoked
Yarn using a relative path (which then ended up being preserved in the
Yarn temporary directory).
We can fix this by updating the Bazel NodeJS repository which seems to
have coincidentally have a fix for the path resolution. See:
https://github.com/bazelbuild/rules_nodejs/pull/3493#event-6870301735.
PR Close#46778
Fixes the Bazel analysis warning and the fact that Yarn is unnecessarily
downloaded by `rules_nodejs`.
```
DEBUG: /home/circleci/.cache/bazel/_bazel_circleci/9ce5c2144ecf75d11717c0aa41e45a8d/external/build_bazel_rules_nodejs/index.bzl:73:14: yarn_install#yarn attribute not set and no repository named 'yarn' exists; installing default yarn
```
PR Close#45892
Update CLDR, which is used to generate the locales files, to version 41.
Also, make necessary code changes to account for changes in the CLDR
data.
Fixes#43301
PR Close#45714
While generating locales, two sets of data (both derived from the
[CLDR project][1]) are used:
- JSON data with the [`cldrjs` package][2], which is used for most
operations.
- XML data with the [`cldr` package][3], which is used for generating
plural-related data.
The JSON data is brought in from the [unicode-org/cldr-json][4]
repository. Since we control the version of the repository that we use,
we can control the CLDR version that these correspond to.
Previously, however, we used the XML data that were bundled with the
[`cldr` package[3]. As a result, the two sets of data could correspond
to different CLDR versions, resulting in incorrect/inconsistent locales
files.
This commit addresses the problem by utilizing the `load()` method of
the [`cldr` package][3], which allows passing in a custom path to the
CLDR XML data (instead of using the bundled data. This way, we can
ensure that the data used for all operations correspond to the same CLDR
version.
Related discussion: #43301
[1]: https://github.com/unicode-org/cldr
[2]: https://www.npmjs.com/package/cldrjs
[3]: https://www.npmjs.com/package/cldr
[4]: https://github.com/unicode-org/cldr-json
PR Close#45714
As mentioned in previous commits (check them for more details), `@bazel/typescript`
no longer contains `ts_library`-specific code, so we no longer need that dependency.
PR Close#45431
Previously devtools used a nested workspace for its bazel configurations. This meant framework dependencies were consumed via npm.
Now devtools is part of the root bazel directory that all other files in this codebase fall under. This allows us to build devtools using local angular packages, removing the need to consume these dependencies with npn. This is useful because we no longer have to update these dependencies with an automated tool like renovate, and our CI tests will always run against the most up to date framework packages.
Paul Gschwendtner