* 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.
This file is currently no longer necessary after migrating all consumers
to their `rules_js` variants, so we can delete the file.
In follow-ups we will consider renaming `defaults2.bzl` back to this
file, or have a better name altogether.
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.
By converting schemas from TypeScript `interfaces` to `types`, we can minimize the reliance on `json.JsonObject`. This approach avoids the error "Type 'Schema' does not satisfy the constraint 'JsonObject'" caused by the missing index signature for type 'string' in 'Schema'.
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.
We'll be using `workspace:*` protocol links to link first-party packages
together in the pnpm workspace. For this reason, we need to make sure
they are properly replaced in `package.json` files, before packaging.
Currently, the `pnpm` and `dependenciesMeta` fields from the root `package.json` are inadvertently copied to the `package.json` of published packages.
For example, see: dc4d5e0d52/package.json (L42-L52)
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.
This is necessary as `rules_js` requires this "common name" when dealing
with Yarn workspaces, linking first party dependencies automatically.
In the future, we may be able to send a PR to `rules_js` to support a
custom name somehow.
Similart to `pkg_npm` from `rules_nodejs`, we should have a way to make
use of the stamp constants/placeholders throughout individual package
files. This is not possible at all with `rules_js`'s `npm_package` rule,
nor does it support stamp substitutions out of the box at all.
We have our own `expand_template` machinery to substitute `package.json`
files of npm archives, but we need to expand this to support arbitrary
files inside a package. This will be opt-in for explicitly listed files;
which is a good compromise for simplicity of supporting this.
This commit adds the necessary functionality and demonstrates the
feature by fixing `@angular/build`.
Migrates the `@angular-devkit/architect` package to the `rules_js` npm
package rule, consuming the direct `rules_ts` output JS files.
Notably, substitution is FAR different than what it used to be with
`rules_nodejs`, so we needed some extra work to leverage `make_template`
for substitutions in `package.json` files. **Keep in mind** that for
now, this does not apply to any other files; so we only substitute in
the `package.json`, but not in e.g. `.js` files as before. We will
follow-up on this.
The other jq merging/filtering for snapshot or tar references in
`package.json` files is kept as is, and is temporarily duplicated. This
is acceptable as the migration should be pretty smooth and quick.
* Removes `interop_deps` from the `ts_project` interop macro.
* Keeps `_rjs` suffix for now as we still need the interop targets for
e.g. `jasmine_node_test` and the `rules_nodejs` linker.
In follow-ups we can remove the suffix, and interop layer.
Currently the interop resulting target of a `ts_project` ends up not
necessarily working at runtime. This may be the case because a consuming
Node program may end up with mixes of `node_modules` dependencies from
`rules_nodejs` (old) and `rules_js` (new). This sounds fine at first
glance, but in practice can break very subtly because:
* Rules NodeJS leverages the linker, creating `node_module` directories
outside of Bazel, at runtime. These don't depend on symlink resolving.
* Rules JS puts real node module folders via Bazel actions. These rely
on `pnpm` non-hoisting layout, and symlink resolving.
As we can see there is a hard conflict with symlinks. They need to be
enabled with the new toolchain, but the other one doesn't enable symlink
resolution, and enabling is not possible as we'd otherwise risk escaping
the sandbox and cause even more subtle errors.
A good compromise solution is to automatically drop the `rules_js` node
module files/folder in the interop-`rules_nodejs` target and instead
brining in the equivalent `@npm//` dependencies from `rules_nodejs`.
This kind of keeps the logic similar to when not using `rules_js` or the
interop, and enables the simplest & safest mental model; and it works
compared to other solutions I tried with symlinking. Notably, we can't
keep both node module variants as the linker doesn't override existing
node module files from e.g. rules_js then (and would break then).
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 is necessary as the current rule is not clever enough to detect
when a given file is already "generated" and inside `bin`.
This is important because `package.json` files are always copied to bin
for `npm_package`, but the `package.json` may already be copied from
e.g. `ts_project#data`. This shouldn't cause a Bazel action conflict.
This commit introduces a new interop Starlark macro/rule for using
`ts_project` throughout the repository without having to migrate
any dependant or dependencies; allowing for incremental migration
to `ts_project`.
The Critters project has been transferred to the Nuxt team, who will now manage its development and has been renamed to Beasties.
See: https://github.com/danielroe/beasties
This commit bundles the Critters library to ensure compatibility with Nodeless environments. Additionally, all licenses for bundled libraries, including Critters, are now included in the package. This helps maintain compliance with open-source license requirements.
Updates for all angular.io links to the new angular.dev domain. Additionally, adjustment to new resources where the equivalent does not exist on the new site (e.g. Tour of Heroes tutorial)
The built packages that will be published on npm previously contained inlined
sourcemaps for every JavaScript file. This caused a significant increase in the
overall package size of over two times larger. This has a negative effect on
developer experience especially the new project experience due to the increase
time to download and setup a new project. The sourcemaps are also rarely used
as debugging the CLI code itself is typically done with development builds.
The generated code is also very close to the original source due to it being
emitted as ES2022 code and with the eventual switch to ESM output this will
become even closer.
As an example of the size difference, the `@angular/cli` compressed package size
was reduced from ~352Kb to ~115Kb with this change.
The JavaScript generated for the published packages is now using ES2022.
This removes additional downleveling of code that was previously necessary
to use newer features.
The minimum Node.js version of 18.13 provides support for the needed features.
While this change does require a patch to `@bazel/concatjs` to allow the target
to be set to `ES2022`, this patch is now already required by the migration of
the universal repository into the CLI repository.
The `@angular/ssr` package does not require the Angular compiler and can instead use the
`ts_library` to compile the TypeScript code. The `@angular/bazel` package has also been
update and a more limited patch is now used due to only needing the `ng_package` rule.
The continued use of the `ng_package` rule maintains the existing output structure for the
`@angular/ssr` package.
