An `ngHmrMode` boolean value will now be defined within application bundles.
The value is based on the development server's `hmr` option with `true`
when HMR is enabled and `false` when disabled. For all application builds,
the value will be `false`. `ngHmrMode` is similar in behavior to `ngServeMode`
or `ngDevMode`. It will not be present in the output code unless referenced
and in those cases only the final boolean value will be present if not optimized
out of the final code.
The value is not considered part of the public API and may change in the future.
The karma configuration will now automatically set the `basePath` option
to the temporary output path when using the application build system's
karma testing. This ensures that only the relative path of the test files
is represented in the stack traces of test failures.
Server-side rendering (SSR) will always enable server routing when using the application builder.
BREAKING CHANGE: `--server-routing` option has been removed from several schematics. Server routing will be used when using the application builder.
This commit promotes the `AngularNodeAppEngine`, `AngularAppEngine`, and `provideServerRouting` APIs from dev preview to stable. These APIs enhance server-side rendering (SSR) capabilities in Angular applications, improving routing and server integration for better performance and reliability.
Prior to this commit, analytics were not recorded for nested schematics. This caused certain data to be incomplete. For example, when running `ng new` and selecting "yes" for SSR in the prompt, this choice was not recorded because the prompt exists within the `application` schematic.
* 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.
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
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.
There can be cases where the `less` stylesheet preprocessor will return
an undefined value for a sourcemap even though sourcemaps have been enabled.
A check is now performed to handle these cases to prevent potential crashes
when processing `less` styles.
When using the development server, the `statsJson` option will now
unconditionally be disabled. The output JSON file is not accessible
with the server and the analysis/generation of the JSON file may
increase the rebuild time. Additionally, the JSON file changes during
a rebuild may unexpectedly cause component HMR fallback to a full
reload due to non-component file changes in the build output.
The Angular schematics have been updated to perform additional checks for
both the `@angular-devkit/build-angular:application` and `@angular/build:application`
builders. This ensures that the schematics generate the appropriate output for
each of these build systems in addition to the Webpack-based `browser` builder.
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.
When executing unit tests with `karma`, the stack traces within errors
will now use any sourcemaps that were generated during the build process
to provide source-based locations for the errors. Script sourcemaps must
be enabled for this functionality.
An `application` only variant of the `karma` builder found within the
`@angular-devkit/build-angular` package is now available within the
`@angular/build` package as `@angular/build:karma`. This builder will
only use the `application` builder found within `@angular/build` and
does not provide the `builderMode` option as `application` would be the
only valid value. Testing behavior is effectively equivalent to using the
`@angular-devkit/build-angular:karma` builder with the `builderMode`
option set to `application`. However, several options have been adjusted:
* `builderMode` was removed
* `fileReplacements` legacy structure (`src`/`replaceWith`) removed
* `polyfills` only accepts an array of strings
* `loader` has been added
* `define` has been added
* `externalDependencies` has been added
This update improves the handling of inlined critical CSS to align with `autoCsp`, ensuring compliance with Content Security Policy (CSP) directives. Previously, inlined styles could trigger CSP violations in certain configurations. With this fix, critical CSS is inlined in a way that maintains security while supporting `autoCsp`.
Closes#29603
