* build: disconnect `@npm` workspace from main project
This will speed up significantly as we don't need to fetch all
dependencies again just for the `@npm` repository that is at this point
only leveraged by the `ng_package` rule for some of its dependencies.
This commit allows us to drop the `yarn.lock` and Aspect lock files, and
allows us to independently migrate `ng_package` to `rules_js`.
It also allows us to drop the `_rjs` TS interop layer in follow-up commits.
* build: drop `_rjs` suffix from `ts_project` targets
We don't need the `ts_project` interop in principle
at this point. We only have one remaining instance left for the SSR
`ng_package` integration. This commit cleans up all usages.
* build: remove yarn
* build: avoid duplicated dependencies at top-level
`rules_js` seems to be sensitive if there are similar versions of the same
package installed, but with differently matched peer dependencies. This
is fine because we can (and should long-term) move those dependencies to
their package-local `package.json` files. This commit unblocks the
migration and highlights how we can move deps to the individual packages
in the future.
* build: update checkout github action
This will allow us to use pnpm.
* build: update node to avoid strict-engines error caused by `npm`
Avoids:
```
Lockfile is up to date, resolution step is skipped
ERR_PNPM_UNSUPPORTED_ENGINE Unsupported environment (bad pnpm and/or Node.js version)
Your Node version is incompatible with "npm@11.2.0".
Expected version: ^20.17.0 || >=22.9.0
Got: v20.11.1
```
Note that we won't update the WORKSPACE test version as that would mean
we need to update the Node engines for shipped packages; and we can't do
this right now without introducing a breaking change.
* build: fix missing dependency for spec bundling
The beasties JS sources weren't available for bundling in the
`bazel-bin`, and this surfaced in RBE. This commit fixes this.
As part of go/ng:windows-dev-future, we are changing how our
infrastructure supports Windows build & testing. Clearly:
- we will still support contributors on Windows, and we believe we will
be improving and streamlining the experience here
- we will continue testing the Angular CLI for our Windows users. We are
aware of the many Windows users using the `ng` CLI.
What is changing? We are no longer actively working towards a Bazel infrastructure
that supports native Windows building and testing. There are currently
two ways to contribute to Angular on Windows. That is via WSL, or via
e.g. native Windows cmd.exe, with Git Bash on top. We acknowledge that
the latter worked sometimes, but we also realize it very often breaks as
nobody on our team uses, verifies it, and it introduces extra complexity
because Bazel on Windows is quite disconnected from Linux/Mac (e.g. no
sandboxing). Going forward, to improve our team's effectiveness, and
improve our stability guarantees for Windows (and Windows contributors),
we are actively discouraging the use of Git Bash for contributing to
Angular; but instead ask for WSL to be used. I can speak as one of the
few long-term team members that have worked on Windows (without WSL) most
of my time, that WSL is great and the contributing experience is much
smoother and also easier to "guide". It's a positive change because we
won't be suggesting "two ways to contribute on Windows", where in
reality one is very brittle and can break at any time!
---
For testing of the Angular CLI: We will continue to maintain the
capability to cross-compile via Bazel with Windows as the target
platform. This allows us to build the e2e tests for Windows, and run
them natively outside WSL to ensure native Windows `ng` CLI testing!
This is what this change mostly does.
Notably, two things are missing here and will be followed up:
- caching of the e2e tests on Windows is not properly functioning yet.
- caching of the WSL node modules + nvm is not working properly yet.
Other than that, we are seeing very similar timing and results of the
Windows tests, so this change unblocks our `rules_js` migration.
Node.js v18 will reach its End-of-Life on 2025-04-30 and as a result will
not be supported with the upcoming Angular v20.
Node.js Release Schedule: https://github.com/nodejs/release#release-schedule
BREAKING CHANGE: Node.js v18 is no longer supported with Angular.
Before updating a project to Angular v20, the Node.js version must be
at least 20.11.1. For the full list of supported Node.js versions,
see https://angular.dev/reference/versions.
Setup requirement for strict_deps throughout repository to ensure that the only dependencies which are imported
are directly provided as dependencies within bazel.
Migrates the `@angular-devkit/build-angular` tests to `rules_js`. This
was a rather larger undertaking as the tests were very reliant on e.g.
the directory structure or specific node module layout; so some changes
were needed.
- the Sass files include a much larger file header now. That is because
the npm Sass files have much larger paths, given being inside a
symlinked pnpm store directory. E.g.
```
/*!**********************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************!*\
!*** css ../../../../../node_modules/.aspect_rules_js/css-loader@7.1.2_webpack_5.97.1/node_modules/css-loader/dist/cjs.js??ruleSet[1].rules[4].rules[0].oneOf[0].use[1]!../../../../../node_modules/.aspect_rules_js/postcss-loader@8.1.1_1462687623/node_modules/postcss-loader/dist/cjs.js??ruleSet[1].rules[4].rules[0].oneOf[0].use[2]!./src/test-style-a.css?ngGlobalStyle ***!
\**********************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************/
.test-a {color: red}
```
- Similarly to above, hashed chunk files can change given different
paths of e.g. Webpack, or external sources.
- Tests for verifying the lazy module chunks may enable
`preserveSymlinks` just to make the chunk names shorter and easier to
verify, avoiding truncatd super long paths to the e.g. pnpm stores
again.
- the ngsw-worker.js file cannot be copied using `copyFile` as that
results in permissions being copied as well. In Bazel, now that
the npm files are properly captured, are readonly, so subsequent
builds (e.g. the watch tests) will fail to copy/override the file
again! Reading and writing the file consistently seems appropriate.
- Tests relying on puppeteer and webdriver-manager worked in the past,
by accident, because postinstall scripts (from e.g. puppeteer) were
able to modify content of other packages (e.g. the puppeteer-core
cache of browsers then). This does not work with `rules_js` anymore,
so we need to keep the cache local to the puppeteer postinstall
script. This requires a little trickery right now to ensure resolution
of the browsers at runtime works..
- server tests did miss the `node` types to be explicitly listed (as
they would be in a fresh project), and this caused failures. Likely
because we no longer patch resolution.
- avoid npm-module style imports from tests within the same package.
This is not allowed with `rules_js` and also is inconsistent.
Migrates the SSR tesst to run natively via `rules_js`. Notably, we still
need the bundling in between as the tests and SSR plain code is not
valid ESM technically; due to lack of extensions.
We'll need to revisit this in the future, or at the very least come up
with a `rules_js`-variant of the `spec_bundle`; but for this is
sufficient and unblocks other packages.
Migrates the schematics-cli tests to `rules_js`.
Notably a little extra logic was needed here as the tests were relying
on the built npm package at runtime, resolvable via it's "package name".
To address this, we manually link the package for the test at runtime.
The spec file is moved into a separate folder for this reason, so that
we don't accidentally expose the schematics CLI package for unexpected
reasons.
Migrates the `@angular-devkit/build-webpack` jasmine tests to
`rules_js`. This requires wiring up in the pnpm workspace.
Additionally `typescript` is added as it was missing as a "peer
dependency" at runtime for `@ngtools/webpack`. This is expected, and
we're already adding other peer deps before this change.
This commit changes the execution of `@angular/pwa` tests to `rules_js`
native `jasmine_test`.
This requires setting it up in the pnpm workspace for first-party linked
dependencies. Notably it turns out the peer dependency placeholder was
incorrect, so we are fixing it here and nicely avoid a problem where
pnpm would otherwise not find a local, or external suitable version.
As we originally tried to work without the fix for the peer dependency
range, there was supported added for extra substitutions. We are keeping
that logic as it will likely be useful in the future.
Integrates `@angular/cli` into the pnpm workspace and wires up the
native `rules_js` rules.
One nice benefits that highlight here:
- `resolve` runtime dependency is only installed in the CLI folder, and
we can pull it from there. --> Locally managed deps! :yay:
Instead of using `rules_nodejs` interop and the linker at runtime, the
test target is migrated to the new `jasmine_test` rule, leveraging the
pnpm workspace for first-party dependencies.
Note that in the future we may be able to rename the local node modules
to something more clear. e.g. `:local_modules/@angular-devkit/core`, but
for now this is not possible :(
This commit shows how similar packages can be migrated in the future.
For the `rules_js` migration we are introducing a new ruleset for
Angular rules. These rules are not used here by the CLI as we don't use
`ng_module`, but we are building the rules in a way where we expose a
worker binary that can also work with vanilla TS.
The worker significantly speeds up compilations, bringing them to
equivalent speeds of `ts_library`, and **importantly** fixes/avoids
issues when actions are executing outside sandbox. E.g. on Windows where
the tsc compilation currently can see many other files that aren't
action inputs; and accidentally picks them up.
This also requires us to move patches from `patch:` protocol to
`patch-package` temporarily. This is because we need to temporarily use
pnpm and yarn berry in hybrid, and both don't have any overlap in how
patching works; and pnpm would fail if it sees the `patch` protocol.
This is necessary for an incremental migration to `rules_js` which
requires Bazel v6. Bazel v6 removed the managed directories feature,
which means we no longer can rely on symlinked node modules as the Bazel
repository; but rather need to duplicate dependencies. This is
okay/acceptable to enable the incremental migration.
This commit introduces the new hybrid rendering API for Angular's Server-Side Rendering (SSR). The API aims to enhance the flexibility of SSR as discussed in https://github.com/angular/angular/discussions/56785
- This API is currently not accessible.
- Additional work is required in the Angular CLI to:
- Wire up the manifest.
- Integrate other necessary components.
