This commit refactors the build process for server-side rendering (SSR) by dividing server assets into separate, importable chunks rather than bundling them into a single output file.
When checking for bundler context invalidation for any referenced files,
the native path format is now used to ensure that the watch files can
be correctly matched. This is particularly important for Windows due to
the differing path segment separator.
Within the development server, the external stylesheet encapsulation logic has been
adjusted to avoid needing to asynchronously import the `@angular/compiler` package within
the request execution. This removes the need to pre-import the package at the start of the
development server which was previously used to avoid a delay in stylesheet response on
first use. The external stylesheet response execution is also now fully synchronous.
If an invalid component identifier is provided to the development server for an external
stylesheet requiring encapsulation, both a console message and a 400 status response will
now be sent. This removes the potential for invalid styles to be sent to the browser.
When using the new developer preview API to serve prerendered pages, ETags are added automatically, enabling efficient caching and content validation for improved performance.
Now that the TypeScript bundler contexts perform additional checks for validity,
they can now be cached in memory during watch modes. This allows the TypeScript
bundler contexts to skip rebundling when not affected by a file changed. This is
particularly beneficial for style related file changes where no code processing
is otherwise required.
When using the development server with the application builder (default for new projects),
the external stylesheet functionality for component style hot replacement was incorrectly
considering SVG files as stylesheet resources. This resulted in a build error when using
SVG files as a template source. The file extension based checks have now been improved to
account for this usage.
The TypeScript-based bundling contexts have now been separated from the other
bundling contexts that may be present in an application build. The later of which
include global styles, scripts, and non-TypeScript polyfills. This allows for
the TypeScript bundling contexts to perform additional checks during a rebuild to
determine if they actually need to be rebundled. The bundling context caching for
the TypeScript contexts has not yet been enabled but these changes prepare for the
switch to allow conditional rebundling on file changes.
The experimental Angular component template hot replacement capabilities
will be initially controlled via an environment variable. Setting `NG_HMR_TEMPLATES=1`
with the development server that is using the application builder will generate the
runtime event code to support hot replacement of an individual component template.
The build system itself does not yet generate the component update build results needed
to trigger the runtime events. The environment variable is currently intended to support
integration of the remaining code to fully implement the feature.
This commit implements the capability for the App Engine to serve prerendered pages directly. Previously, we relied on frameworks like Express for this functionality, which resulted in inconsistent redirects for directories where in some cases a trailing slash was added to the route.
**Note:** This change applies only when using the new SSR APIs. When using the `CommonEngine`, a 3rd party static serve middleware is still required.
A bundle call for a `BundlerContext` can now force a rebundling in cases
where the cached version should not be used. This is currently not leveraged
within the code but will be used for improvements to typescript based context
rebuilds in the future.
When using the development server with the application builder, file-based component
styles will now be bundled during the main builder execution instead of within the
application code bundling step. This allows for these styles to be processed independently
from any code bundling steps and will support future changes that will allow the
builder to completely skip code bundling if only file-based component stylesheets are changed.
When using the development server with the application builder, external
component stylesheet usage must always be record to ensure that any hot
replacement actions correctly reference the relevant components. Previously,
browser cached styles would return a 304 status prior to recording the usage.
This resulted in the development server not knowing that the component needed
a potential update in the future.
When using the development server with the application build system,
resource files managed by the build system will now using ETag headers
to avoid resending content that has not changed since the last request.
This includes such content as global stylesheet files, image/font files
referenced in stylesheets, and other files managed by the bundler.
The Critters project has been transferred to the Nuxt team, who will now manage its development and has been renamed to Beasties.
See: https://github.com/danielroe/beasties
When using the development server, Angular component stylesheet requests that
use hot replacement (default for v19) will now use the `ETag` header to remove
the need to reprocess and resend encapsulated component styles if the styles
have not changed since last usage. The ETag value used is a combination of the
style content and the encapsulation component identifier.
When `outputMode` is configured, `--prerender` and `--app-shell` become no-ops, making server feature disabling difficult without modifying the configuration.
This commit introduces the `--no-server` option, which can be used with `--output-mode static` to fully disable all server features.
```
ng build --output-mode static --no-server
```
When using the development server with a production configuration or with bundle
hashing enabled, the external stylesheet files used by the development server for
hot replacement of component styles are no longer hashed. This ensures that the
requests from the runtime served by the development server match the available
generated component stylesheet files.
In Node.js 20, changes to ESM loader hooks result in the `--import` execArgv being passed from the parent to child workers.
This commit resolves the issue by setting an empty `execArgv` in the JavaScript transformer, preventing unintended propagation.
Closes#28683
Following up on the logic provided in #28639, we want to offer an opt-in
option in angular.json to enable the auto-CSP transformation.
For now, builds for `ng serve` will have Auto-CSP disabled.
Auto-CSP is a feature to rewrite the `<script>` tags in a index.html
file to either hash their contents or rewrite them as a dynamic loader
script that can be hashed. These hashes will be placed in a CSP inside a
`<meta>` tag inside the `<head>` of the document to ensure that the
scripts running on the page are those known during the compile-time of
the client-side rendered application.
The internal AOT Angular compilation processing can now generate the newly
introduced template update functions during development server rebuilds of
template only file changes. These template update functions are not yet used
but provide the infrastructure to enable template hot replacement in a
future change.
The component stylesheet bundler is now created at the start of the build
and accessible prior to the bundling actions. This will provide support for
generating updated component styles and bypassing all code bundling when using
the development server and only component styles have been modified.
The component stylesheet bundler is now created during the setup of the Angular
compiler plugin options. This is an initial step to support more fine-grained
rebuild actions with the new component stylesheet development server support.
The `StartTag` and `EndTag` types are now also exported along with the
`htmlRewritingStream` factory. These types are commonly used with the
rewriter and by exporting them reduces the need to manually extract them
from the underlying methods.
When using the `application` builder (default for new projects) with the
development server, component style only changes will now automatically
replace the styles within the running application without a full reload
of the page. No application code changes are necessary and both file-based
(`styleUrl`/`styleUrls`) and inline (`styles`) component styles are supported.
Within a component template, `<style>` elements and `<link rel="stylesheet">`
elements with relative `href` attributes are also supported.
If any issues are encountered or it is preferred to not hot replace component
styles, the `NG_HMR_CSTYLES=0` environment variable can be used to disable
the feature. Setting the `liveReload` option to false will also disable all
updates.
When using the application builder with `isolatedModules`, the bundler will
directly handle TypeScript transpilation and bundling. Previously, any input
TSX files were loaded by the bundler as TS files. This difference caused errors
when attempting to process the files since the syntax differs between TSX and TS.
The appropriate loader will now be used if the input file is TSX in this situation.
This commit introduces the functionality to configure a limited number of options for Sass processing in the Angular application builder. The following options have been added to enhance the Sass integration:
- **futureDeprecations**: Specifies features that are scheduled for deprecation. The compiler will treat these as active and emit warnings as necessary.
- **fatalDeprecations**: Identifies Sass features that are already deprecated and will cause build failures if used.
- **silenceDeprecations**: This option suppresses deprecation warnings for specified versions.
Usage example:
```json
"architect": {
"build": {
"builder": "@angular-devkit/build-angular:application",
"options": {
"outputHashing": "none",
"namedChunks": true,
"stylePreprocessorOptions": {
"sass": {
"futureDeprecations": ["color-functions"],
"fatalDeprecations": ["color-functions"],
"silenceDeprecations": ["1.77.0"]
}
}
}
}
}
```
For more information about these options, please refer to the Sass documentation: https://sass-lang.com/documentation/js-api/interfaces/options/Closes#28587
To improve type-checking and reduce hard to diagnose errors when using the new
`production`/`development` conditions, the set of conditions used by the bundler
are now also synchronized with those used by TypeScript. This helps ensure
that type mismatches are avoided by type-checking against the actual file that
will be bundled into the output.
On slow systems, a race condition can lead to the sass worker thread
being notified to wake up before a message is posted. This causes the
build to be aborted because the searched file is not found.
Waiting twice for a non-zero number in the signal handles this race
correctly, and the second wait should be a noop in the usual case.
Fixes#27167
