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.
* 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.
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.
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.
Ensures that the SSR router gives precedence to the first matching route, addressing the issue where later conflicting routes.
This change prevents the incorrect prioritization of routes and ensures the intended route is matched first, aligning routing behavior.
Closes: #29539
This commit adds support for custom route matchers in Angular SSR, allowing fine-grained control over the `renderMode` (Server, Client) for individual routes, including those defined with matchers.
Routes with custom matchers are **not** supported during prerendering and must explicitly define a `renderMode` of either server or client.
The following configuration demonstrates how to use glob patterns (including recursive `**`) to define server-side rendering (SSR) or client-side rendering (CSR) for specific parts of the 'product' route and its child routes.
```typescript
// app.routes.ts
import { Routes } from '@angular/router';
export const routes: Routes = [
{
path: '',
component: DummyComponent,
},
{
path: 'product',
component: DummyComponent,
children: [
{
path: '',
component: DummyComponent,
},
{
path: 'list',
component: DummyComponent,
},
{
matcher: () => null, // Example custom matcher (always returns null)
component: DummyComponent,
},
],
},
];
```
```typescript
// app.routes.server.ts
import { RenderMode, ServerRoute } from '@angular/ssr';
export const serverRoutes: ServerRoute[] = [
{ path: '**', renderMode: RenderMode.Client },
{ path: 'product', renderMode: RenderMode.Prerender },
{ path: 'product/list', renderMode: RenderMode.Prerender },
{ path: 'product/**/overview/details', renderMode: RenderMode.Server },
];
```
Closes#29284
Switches the beasties bundling to `rules_js`, using rollup directly from
the node modules installation.
Notably we are facing a small issue that doesn't cause any issues right
now, because rollup tries to dereference symlinks by default given
a bug: https://github.com/aspect-build/rules_js/issues/1827.
This means we can't rely on the jailed resolution, but in practice it
shouldn't cause an issue at this point.
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.
When redirecting to the preferred locale, the previous implementation used the full URL for the 302 redirect to i18n subpaths based on the user's preferred locale. This update ensures that the redirect now uses the locale-specific pathname instead of the full URL.
Closes#29514
This commit renames `provideServerRoutesConfig` to `provideServerRouting` and updates the second parameter to use the `ServerRoutes` features.
This change improves alignment with the framework's API conventions and the way features are integrated.
### Example Usage:
Before:
```typescript
provideServerRoutesConfig(serverRoutes, { appShellRoute: 'shell' })
```
After:
```typescript
provideServerRouting(serverRoutes, withAppShell(AppShellComponent))
```
Updated route matching logic to prioritize closest matches, improving the accuracy of dynamic route resolution. Also we optimized performance by eliminating unnecessary recursive checks, reducing overhead during route matching.
Closes#29452
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.
This change modifies the `getPathSegments` function to use `stripTrailingSlash`, providing a more consistent and reliable way to handle trailing slashes in paths. This update also resolves issues causing CI failures.
This fix ensures that catch-all routes (e.g., wildcard routes like `**`) are handled correctly when a base href is configured in an Angular SSR application.
Closes#29397
Although route matchers are not supported with the SSR Routing API, they still function with the legacy `CommonEngine`. Therefore, no error should be issued in this case.
Closes#29420
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.
Refined and clarified the descriptions for various schematics options to improve their readability and accuracy. These changes aim to make the documentation more user-friendly and accessible for developers.
Closes#25571
Previously, when the application was served behind a proxy, server-side redirects generated an incorrect Location header, causing navigation issues. This fix updates `createRequestUrl` to use the port from the Host header, ensuring accurate in proxy environments. Additionally, the Location header now only contains the pathname, improving compliance with redirect handling in such setups.
Closes#29151
A timeout was added during route extraction to resolve an issue where 'adev' would hang in production builds.
The root cause is currently unclear, but this change ensures the build completes successfully.
