* 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.
BREAKING CHANGE: The `NodePackageLinkTask` has been removed without a replacement. Create a custom task if needed.
Note: This does not affect application developers.
Currently when operating within a pnpm workspace and leveraging the
schematic test runner, there are situations where e.g.
`@schematics/angular` cannot be resolved. Consider this pnpm node
modules structure:
```
packages/
pwa/
node_modules/@schematics/angular --> .pnpm-store/@schematics/angular/...
node_modules/@angular-devkit/schematics --> .pnpm-store/@angular-devkit/schematics/...
index_spec.js // trying to call external schematic `@schematics/angular`
```
This above setup will fail because `@schematics/angular` is attempted to
be resolved from within the devkit schematics code, which doesn't have
access, or a dependency on `@schematics/angular`. We can use the
specified collection of the test runner to determine a good "resolution
lookup site", similiar to how it happens with the real `ng update`
command.
Migrates `@angular-devkit/schematics` jasmine rules to the
native `rules_js` variant.
As part of this commit, we are performing a few adjustments that we've
discussed as preparation for this migration:
- cross package imports are always using the module name
- inside package imports are always using relative imports, matching
existing tests, fixing a few outliers.
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:
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.
The `Rule` type has been updated to align with its intended functionality, allowing it to return a `Promise<Tree>`. Previously, this behavior was supported but not properly typed.
Closes#22783
* 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.
The `@angular-devkit/schematics` package has been migrated to the `rules_js` ts_project rule.
The tsconfig path mappings for the `@angular-devkit` scope have also been cleaned up now that
all the packages within this scope have been migrated.
The file system engine hosts for schematics were using a helper method to
read JSON files that was performing both an exist and read call. Besides
causing two file system calls, this also has a potential race condition
where the file may not exist by the time the read call is made. To avoid
this, a try/catch is used with the read call to handle the not existing
case.
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 TypeScript `isolatedModules` option is now enabled for all TypeScript
code within the repository. As a result, all packages will now be built
with the option enabled. This does not affect projects created with the CLI
and is only related to the building of the actual Angular CLI code.
The `isolatedModules` option ensures that code can be emitted without the
TypeScript typechecker and allows tools other than TypeScript to potentially
be used. Code was updated to correct all errors after the option was enabled.
Additionally, some early code fixes were done to add function and accessor
return types to prepare for future `isolatedDeclarations` usage. More changes
would be needed to consider turning on `isolatedDeclarations`, however.
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)
All direct usage of rxjs has been removed from the FilterHostTree implementation.
This removes the need to import rxjs within the containing file. The recursive
logic has also been replaced with an iterative approach.
The schematics `UpdateRecorder` now uses the `magic-string` library directly instead
of delegating to another class (`UpdateBuffer`) which now effectively only wraps the
`magic-string`. This also allows for improved BOM handling and repeat conversion
of strings to and from `Buffer` instances.
Currently, when using `ng new` on Windows, users will get a number of `LF will be replaced by CRLF the next time Git touches it` warnings.
This commit, replaces the line endings in templates to be platform specific.
Closes#26764
