* 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.
If the chunk happens to end in a new line or other meaningful
whitespace, stripping it can lead to two words (e.g. targets)
being squished together and broken.
This script will be very useful for the `rules_js` migration, as it
allows us to quickly spot differences between the local `npm_package`
target and the valid golden (based on the snapshot repository).
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.
I often struggle with spacing around block comments, so I've decided to add the `lines-around-comment` lint rule to help manage this.
For more details, see the https://eslint.style/rules/js/lines-around-comment
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.
The `@typescript-eslint/eslint-plugin` package has been updated to v8.0.1.
With new major versions of the package, additional rules are added to the
default recommended list. Several such new rules have been disabled to
minimize the code changes to update the package. Several minor type only
fixes were however included to reduce the number of disabled rules.
Several smaller code changes to improve type information and remove now
unneeded code structures based on improvements to both Node.js, TypeScript,
and underlying dependencies.
The saucelabs connect tunnel utility is now only downloaded when a
saucelabs related test is executed. Previously it was part of the
root `package.json` and downloaded whenever a package install was
executed. The utility archive was also not an actual package which
incidentally worked with npm but does not work with newer versions
of yarn. A SHA256 check is also now performed prior to executing
the utility to verify the expected file is present.
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)
Dependency know leverages the Github dependency review action instead
of the previous custom solution. The action uses the Github dependency
API to analyze dependencies. This not only should provide more accurate
results but also lower the maintenance costs for the license checking.
The initial allowed licenses list is based on the previous checker list
with licenses that are no longer used removed.
Action Documentation: https://github.com/actions/dependency-review-action
The separate `lodash.template` package appears to no longer be updated.
To address https://github.com/angular/angular-cli/security/dependabot/87
the package has been switch to `lodash` which is the main package and
was updated to address the linked issue. This package is used within
the build infrastructure tooling for the repository.
The admin create script previously only updated the package.json dependencies
for direct dependencies. This did not ensure that all built packages were used
due to some built packages being used as transitive dependencies. The npm
`overrides` field is now also used to ensure that these dependencies are also
properly redirected to the built packages.
Previously, the release process encountered an error due to ts-node's inability to transform `packages/schematics/angular/utility/latest-versions.ts`, resulting in the following error:
```
export const latestVersions: Record<string, string> & {
^^^^^^
SyntaxError: Unexpected token 'export'
at internalCompileFunction (node:internal/vm:73:18)
at wrapSafe (node:internal/modules/cjs/loader:1274:20)
at Module._compile (node:internal/modules/cjs/loader:1320:27)
at Module._extensions..js (node:internal/modules/cjs/loader:1414:10)
at Module.load (node:internal/modules/cjs/loader:1197:32)
at Module._load (node:internal/modules/cjs/loader:1013:12)
at ModuleWrap.<anonymous> (node:internal/modules/esm/translators:202:29)
at ModuleJob.run (node:internal/modules/esm/module_job:195:25)
at async ModuleLoader.import (node:internal/modules/esm/loader:336:24)
at async checkSchematicsAngularLatestVersion (file:///usr/..../git/angular-cli/scripts/release-checks/dependency-ranges/latest-versions-check.mts:9:46)
```
To resolve this issue, we now utilize the `package.json` directly to retrieve dependency versions.
This update addresses an issue where an older version of the CLI tarball was mistakenly employed in creating a new application via `yarn admin create`.
Additionally, `yarn admin create` now accommodates extra options that can be utilized with `ng new`.
Example:
```
yarn admin create my-app --ssr
```
This should fix
```
fatal: 'c22bda9
' is not a valid tag name.
Command failed: git "tag", "c22bda9\n"
file:///home/runner/work/angular-cli/angular-cli/scripts/devkit-admin.mts:39
console.error(err.stack);
```
The helpers are unneeded and behavior can be reproduced with direct
string usage. Also, this removes a runtime dependency on the packages
being validated.
The main release build script now has the infrastructure needed to build
using the `local` bazel configuration. This is not yet used within the build
process but provides the base infrastructure to support local builds of the
packages in the future. `local` builds are package builds that contain file
path dependencies to the other built package archives in the workspace and
are used for local development and testing purposes only.
Previously, the `@angular/core` package which was being built was used
during the build process. This package was only used for logging and
has now been replaced with the Console instead. This prevents potential
logging issues if there are bugs or errors within the package being built.
The `fs-monkey`, `memfs` and `spdx-license-ids` packages all now have valid license
fields and allowed licenses. All three have been removed from the exceptions
list.
Several SPDX license aliases have been removed as they are no longer used
by any dependencies within the project. The aliases only existed due to
previous non-standard SPDX identifiers present in used packages.
Additionally, the license validator automatically handles SPDX combination
syntax and combinations do not need to be listed explicitly.
The file searching within the build system (both Webpack and esbuild) now use the
`fast-glob` package for globbing which provides a small performance improvement.
Since the assets option in particular is within the critical path of the buil pipeline,
the performance benefit from the switch will be most prevalent in asset heavy projects.
As an example, the Angular Material documentation site saw the asset discovery time
reduced by over half with the switch. `fast-glob` is also the package used by Vite
which provides additional benefit by ensuring that the Angular CLI behavior matches
that of the newly integrated Vite development server.
Adds an automatic check that runs before cutting releases. This
will help avoiding issues where we forget to update peer dependencies
or the `latest-versions.ts` file.
