The Angular CLI will now enable the Node.js compile cache when available
for use. Node.js v22.8 and higher currently provide support for this feature.
The compile cache stores the v8 intermediate forms of JavaScript code for the Angular
CLI itself. This provides a speed up to initialization on subsequent uses the Angular CLI.
The Node.js cache is stored in a temporary directory in a globally accessible
location so that all Node.js instances of a compatible version can share the
cache. The code cache can be disabled if preferred via `NODE_DISABLE_COMPILE_CACHE=1`.

Based on initial profiling, this change provides an ~6% production build time
improvement for a newly generated project once the cache is available.

```
Benchmark 1: NODE_DISABLE_COMPILE_CACHE=1 node ./node_modules/.bin/ng build
  Time (mean ± σ):      2.617 s ±  0.016 s    [User: 3.795 s, System: 1.284 s]
  Range (min … max):    2.597 s …  2.640 s    10 runs

Benchmark 2: node ./node_modules/.bin/ng build
  Time (mean ± σ):      2.475 s ±  0.017 s    [User: 3.555 s, System: 1.354 s]
  Range (min … max):    2.454 s …  2.510 s    10 runs

Summary
  node ./node_modules/.bin/ng build ran
    1.06 ± 0.01 times faster than NODE_DISABLE_COMPILE_CACHE=1 node ./node_modules/.bin/ng build
```

…integration

Expose a variant of `AngularAppEngine` tailored for Node.js. These additions streamline the process by minimizing boilerplate code and eliminate the need for users to call `createWebRequestFromNodeRequest` before invoking the render method.

… `AngularNodeAppEngine` for handling pages static headers

This commit introduces a new `getHeaders` method to the `AngularAppEngine` and `AngularNodeAppEngine` classes, designed to facilitate the retrieval of HTTP headers based on URL pathnames for statically generated (SSG) pages.

```typescript
const angularAppEngine = new AngularNodeAppEngine();

app.use(express.static('dist/browser', {
  setHeaders: (res, path) => {
    // Retrieve headers for the current request
    const headers = angularAppEngine.getHeaders(res.req);

    // Apply the retrieved headers to the response
    for (const { key, value } of headers) {
      res.setHeader(key, value);
    }
  }
}));
```

In this example, the `getHeaders` method is used within an Express application to dynamically set HTTP headers for static files. This ensures that appropriate headers are applied based on the specific request, enhancing the handling of SSG pages.

This commit removes the singleton helpers and instead exposes the
classes directly.

….js reference in manifest

The issue was addressed by changing the top-level import to a dynamic import.

Closes #28358

The existing instructions don't quite cover a full debugging setup
and miss some flags that allow debugging without modification of
BUILD files.

Updates a few leftover places to the TypeScript 5.6 final version.

…rred types

This refactor resolves an issue where the inferred type of `renderSassStylesheet` required an external reference, which could affect portability.

Fixes the following error:
```
packages/angular/build/src/tools/sass/worker.ts:59:31 - error TS2742: The inferred type of 'renderSassStylesheet' cannot be named without a reference to '../../../../../../external/npm/node_modules/source-map-js/source-map'. This is likely not portable. A type annotation is necessary.
```
Explicit type annotation added to `renderSassStylesheet` function to prevent reliance on inferred types.

**Note:** Ensure compatibility with Windows Bazel builds.

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

…dencies by Vite

This commit excludes Node.js module imports from being processed by Vite when prebundling is enabled.

Closes #28390

We recently introduced the ability to pass object values from the
command line (#28362). @clydin noticed that the initial behavior
didn't work well for `--define`: It completely replaced all values
even if just one of multiple defines is specified.

This updates the architect to support merging of object options.
If both the base option (e.g. from `angular.json`) and the override
(e.g. from a CLI `--flag`) are objects, the objects are merged.

See: #28362

…erving

The Vite-based development server now provides support for serving individual
component stylesheets both with and without emulated view encapsulation. This
capability is not yet used by the Angular runtime code. The ability to use
external stylesheets instead of bundling the style content is an enabling
capability primarily for automatic component style HMR features. Additionally,
it has potential future benefits for development mode deferred style processing
which may reduce the initial build time when using the development server. The
application build itself also does not yet generate external stylesheets.

Remove unused imports from command-module file.

…d type

The `Readonly` mapped type only introduces the `readonly` modifier for each property,
but `Map` has mutating methods like `clear`, `delete` and `set` that would still
remain usable. This commit switches those usages over to the `ReadonlyMap` type which
doesn't have any of the mutating methods.

In cases where the application is not zoneless and async/await is downleveled, an issue occurred where `await` was not being downleveled correctly. This led to the `bootstrap is not a function` error.

See: https://github.com/angular/angular/actions/runs/10817795242/job/30014914340?pr=57776

This commit introduces a new server routing configuration API, as discussed in RFC angular/angular#56785. The new API provides several enhancements:

```ts
const serverRoutes: ServerRoute[] = [
  {
    path: '/error',
    renderMode: RenderMode.Server,
    status: 404,
    headers: {
      'Cache-Control': 'no-cache'
    }
  }
];
```

```ts
const serverRoutes: ServerRoute[] = [
  {
    path: '/product/:id',
    renderMode: RenderMode.Prerender,
    async getPrerenderPaths() {
      const dataService = inject(ProductService);
      const ids = await dataService.getIds(); // Assuming this returns ['1', '2', '3']
      return ids.map(id => ({ id })); // Generates paths like: [{ id: '1' }, { id: '2' }, { id: '3' }]
    }
  }
];
```

```ts
const serverRoutes: ServerRoute[] = [
  {
    path: '/product/:id',
    renderMode: RenderMode.Prerender,
    fallback: PrerenderFallback.Server, // Can be Server, Client, or None
    async getPrerenderPaths() {
    }
  }
];
```

```ts
const serverRoutes: ServerRoute[] = [
  {
    path: '/product/:id',
    renderMode: RenderMode.Server,
  },
  {
    path: '/error',
    renderMode: RenderMode.Client,
  },
  {
    path: '/**',
    renderMode: RenderMode.Prerender,
  },
];
```

These additions aim to provide greater flexibility and control over server-side rendering configurations and prerendering behaviors.

…ailable"

This reverts commit ecc107d.

…nding

Replaced multiple `appendServerConfiguredHeaders` calls with a single custom middleware to append headers to all responses, simplifying the code and ensuring consistency.

…etter debugging

Naming the custom middleware improves the ability to identify middleware order during debugging.

This commit introduces the following changes:
- Disallows paths starting with a slash to match Angular router behavior.
- Errors are now stored and displayed at a later stage, improving UX by avoiding unnecessary stack traces that are not useful in this context.

Adds a new function `isMainModule` that checks if the current module is the main entry point of the application.

This is useful to ensure that server listener handlers are only registered when the module is executed directly and not when it's imported as a dependency such as the dev-server. This prevents potential issues with multiple listeners being registered unintentionally.

…m extraction

This option allows validation during the build process to ensure that, when the output mode is set to static, no routes requiring server-side rendering are included.

The Angular CLI will now enable the Node.js compile cache when available
for use. Node.js v22.8 and higher currently provide support for this feature.
The compile cache stores the v8 intermediate forms of JavaScript code for the Angular
CLI itself. This provides a speed up to initialization on subsequent uses the Angular CLI.
The Node.js cache is stored in a temporary directory in a globally accessible
location so that all Node.js instances of a compatible version can share the
cache. The code cache can be disabled if preferred via `NODE_DISABLE_COMPILE_CACHE=1`.

Based on initial profiling, this change provides an ~6% production build time
improvement for a newly generated project once the cache is available.

```
Benchmark 1: NODE_DISABLE_COMPILE_CACHE=1 node ./node_modules/.bin/ng build
  Time (mean ± σ):      2.617 s ±  0.016 s    [User: 3.795 s, System: 1.284 s]
  Range (min … max):    2.597 s …  2.640 s    10 runs

Benchmark 2: node ./node_modules/.bin/ng build
  Time (mean ± σ):      2.475 s ±  0.017 s    [User: 3.555 s, System: 1.354 s]
  Range (min … max):    2.454 s …  2.510 s    10 runs

Summary
  node ./node_modules/.bin/ng build ran
    1.06 ± 0.01 times faster than NODE_DISABLE_COMPILE_CACHE=1 node ./node_modules/.bin/ng build
```

When using the development server, HTTP HEAD requests will now correctly
respond for the virtual output files generated from the Angular build
system.  Previously Vite only handled GET requests for the files. While
HEAD requests are not common in development workflows, it can be needed in
more complex cases with additional servers/proxies/etc. during development.

Resolves some type errors that showed up internally.