* 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.
To align with the updated style guide, Angular v20 will generate
component templates with a `.ng.html` file extension instead of
the previous `.html` by default. Projects will automatically
use this new template extension. Projects can however opt-out of
component generation using `.ng.html` by setting the `ngHtml`
option to false for the component schematic. This can be done as
a default in the `angular.json` or directly on the commandline
via `--no-ng-html` when executing `ng generate`.
The configuration now ensures that when a package is listed for exclusion, all paths within that package including sub-paths like `@foo/bar/baz` are marked as external and not prebundled by the development server.
For example, specifying `@foo/bar` in the exclude list will prevent the development server from bundling any files from the `@foo/bar` package, including its sub-paths such as `@foo/bar/baz`.
This aligns with esbuild external option behaviour https://esbuild.github.io/api/#externalCloses#29170
Newly generated projects will now use the `preserve` value for the `module` option
within the TypeScript configuration for the workspace (`tsconfig.json`). This value
was added in TypeScript 5.4 and is intended to model the behavior of modern bundlers
such as used in the default `application` builder.
This option value also has the advantage of automatically enabling `esModuleInterop`
and setting `moduleResolution` to `bundler` which are the currently generated values
for new projects. This allows explicit use of these options to be removed from the generated
file. The `resolveJsonModule` option is also enabled with `preserve` which removes
the need for developers to manually add it if JSON files are imported. JSON file imports
are fully support including unused property treeshaking with named imports in the
`application` builder.
Additional details on the option can be found here:
https://www.typescriptlang.org/docs/handbook/release-notes/typescript-5-4.html#support-for-require-calls-in---moduleresolution-bundler-and---module-preserve
The `@angular/build` package is now used directly within all newly created
projects and replaces the previous usage of the `@angular-devkit/build-angular`
package. This has the advantage of removing the need to install all of the
Webpack related transitive dependencies contained within `@angular-devkit/build-angular`
that are used to support the `browser` builder. This results in a significant
reduction in both total dependency count and disk install size for new projects.
New projects that would prefer to use the Webpack-based `browser` builder can still
install the `@angular-devkit/build-angular` package within the workspace.
The `@angular/build@19.2.0-next.2` package currently has a total unpacked size of ~115 MB.
The `@angular-devkit/build-angular@19.2.0-next.2` package currently has a total unpacked size of ~291 MB.
Previously, component styles were included in the 'any' and 'all' budgets, which could lead to incorrect budget violations. This update ensures that component styles are excluded from these budget calculations.
Closes#29609
Improves SSR performance by streaming the response before inlining critical CSS. This allows for earlier header flushing, reducing time to first byte (TTFB) and improving perceived load times.
When the service worker option is enabled, each code update will cause
the `ngsw.json` configuration file to change due to the different hashes
of the updated output. This is problematic for component HMR usage with
the development server since the full reload fallback logic would be triggered
due to the changed `ngsw.json` file. To avoid this problem, the `ngsw.json`
configuration file is now special cased within the fallback logic.
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.
When on Windows, the coverage exclusion paths need to be made
absolute via the Node.js path builtin to ensure matching
with the files during the build process.
Usage of the `fast-glob` package has been replaced with the `tinyglobby`
package throughout `@angular/build`. The change reduces the number of
transitive dependencies related to these packages from 17 to 2 while
also maintaining equivalent functionality. Additionally, the `tinyglobby`
package is used by other dependencies such as `vite` and `copy-webpack-plugin`
which has the potential to further reduce overall transitive dependencies
for a project.
Previously, JIT component resource URLs in sourcemaps included a `file:` prefix (e.g., `file:src/app/app.component.html`). This change removes the `file:` prefix to ensure cleaner source mappings.
BREAKING CHANGE: The `NodePackageLinkTask` has been removed without a replacement. Create a custom task if needed.
Note: This does not affect application developers.
