The new routing APIs don't support `browser` builder, but calling `ng add @angular/ssr` with a `browser` builder would still prompt the user to add them. If the user said "Yes", it would actually ignore that answer and not enable the new APIs.
With this change, `ng add @angular/ssr` when using `browser` builder does not show the prompt and assumes the answer is "No". It also throws an error if the user runs `ng add @angular/ssr --server-routing`.
I'm not aware of a built-in prompting mechanism in schematics beyond `x-prompt`, which can't be used here, so instead I just called Inquirer directly. Unfortunately testing the prompt is a little awkward, as Inquirier does not provide useful APIs in this space. I evaluated `@inquirer/testing`, but ultimately decided that was more intended for testing custom Inquirer prompts, not mocking usage of standard prompts. Schematics APIs do not provide a useful way to inject additional data like a mock, so instead I had to do this through a `setPrompterForTestOnly` function. I'm not a huge fan of it, but I don't see a more straightforward way of solving the problem.
The component stylesheet HMR functionality requires build-time analysis
of each component by the AOT compiler to provide the needed information
to identify initial styles and detect individual changes to each style.
Part of the style HMR rebuild logic was unintentionally enabled in JIT
mode. The initial load of the application operated correctly but subsequent
changes to file-based stylesheets were delayed by one rebuild cycle. To
avoid this misalignment, all component stylesheet HMR functionality is
now disabled when in JIT mode.
Importing `PrerenderFallback` in a project throws at build time in 19.0.0-rc.2 with:
```ts
✘ [ERROR] No matching export in "node_modules/@angular/ssr/fesm2022/ssr.mjs" for import "PrerenderFallback"
src/app/app.routes.server.ts:1:9:
1 │ import { PrerenderFallback, RenderMode, ServerRoute } from '@angula...
```
This exports `PrerenderFallback` the same way `RenderMode` is exported to fix the issue.
Sass variable namespaces can contain either a hyphen or underscore in the namespace
identifier. The URL rebasing support within the Angular CLI will now account for
these type of namespaces and rebase the evaluated URL as expected.
Previously the `fileReplacements` option within the `application` builder
would only replace `.js` files if the TypeScript `allowJs` option was enabled.
This differs from the `browser` builder which did not require the option.
To minimize friction when migrating to the new build system, the `allowJs`
option is no longer required for this file replacement case.
This commit removes the `RenderMode.AppShell` option. Instead, a new configuration parameter, `{ appShellRoute: 'shell' }`, is introduced to the `provideServerRoutesConfig` method.
```ts
provideServerRoutesConfig(serverRoutes, { appShellRoute: 'shell' })
```
Corrected an issue where a redirect was not properly included in the SSR (Server-Side Rendering) manifest. This fix ensures that all necessary redirects are accounted for during the build process.
A component may contain multiple inline styles that will originate from the
same containing file. The content of the processed style is sent directly
to the Angular compiler. However, any additional result files are collected
and emitted in the application output. In most cases, this worked as expected
as inline styles rarely had resource references that would overwrite each other.
However, the potential is present for later inline styles for a component to
overwrite these output files. To avoid this potential problem, the internal
identifier now accounts for both the class name and order of the inline styles.
This ensures that each inline style retains a unique additional results entry.
This commit initializes the `REQUEST`, `RESPONSE_INIT`, and `REQUEST_CONTEXT` DI tokens with `null` values by default.
Previously, these tokens lacked default values, which meant that developers had to explicitly mark them as optional when injecting them in constructors. This was necessary to avoid errors when these tokens were not provided, particularly in scenarios like client-side rendering or during development.
By initializing these tokens with `null`, we eliminate the need for developers to mark them as optional, simplifying the code and improving the developer experience.
When using the development server with the application builder, the internal state of
any external component stylesheets is now more comprehensively tracked. This allows
for more flexibility in both debugging potential problems as well as supporting additional
stylesheet preprocessing steps including deferred component stylesheet processing.
This commit cleans up duplicate code left from the previous implementations of process, serve, and render. Additionally, prerender serve now exclusively handles HEAD and GET requests, aligning with updated handling requirements. The private `renderStatic` method has been removed in favor of the `handle` method for improved maintainability.
Added `@developerPreview` annotations to the relevant API functions and properties within the `@angular/ssr` package. This change ensures that the documentation accurately reflects the preview status of these elements, clarifying their intended use and stability level for developers.
Improve the documentation `adev` API reference by incorporating `@see` references. This addition enhances cross-referencing within the documentation, making it easier for users to navigate related content and gain better context.
Introduced an error check to ensure that 'provideServerRoutesConfig' is not utilized in the browser part of the application. This helps avoid unintended behavior.
When using the development server with the application builder (default for new projects),
Angular components using ShadowDOM view encapsulation will now cause a full page reload.
This ensures that these components styles are correctly updated during watch mode. Vite's
CSS hot replacement client code currently does not support searching and replacing `<link>`
elements inside shadow roots. When support is available within Vite, an HMR based update
for ShadowDOM components can be supported as other view encapsulation modes are now.
Updated TSDoc comments by replacing @note with @remarks across the codebase. This aligns with TSDoc's preferred conventions, where @remarks is used for supplementary explanations and additional context.
When live reload is disabled (`"liveReload": false`/`no-live-reload`) within
the development server, the Vite websocket server will no longer be initialized.
Additionally, the client code will not be loaded by the browser. This allows the
development server to be used in test scenarios that would prefer to more fully
represent the production fielded configuration such as E2E testing or other forms
of browser-based testing.
The development server's `hmr` option will now disable both global and component
stylesheet hot replacement if explicitly disabled. These features are enabled by
default for all projects.
When using the development server with the application builder (default for new projects),
experimental support for component template hot replacement is now available for use. To
enable support, the `NG_HMR_TEMPLATES=1` environment variable must present when executing
the development server (for example, `NG_HMR_TEMPLATES=1 ng serve`). Once support has become
stable, template hot replacement will be enabled by default.
Now that additional result object types can be returned from the build
system, the error overlay must be cleared on all non-error results. The
introduction of component update results and eventual incremental results
will now properly clear the error overlay after a successful build.
Updated the calculation to use `Buffer.byteLength()` for determining the length of escaped file content. This change ensures that the `size` property in server asset metadata accurately represents the length of the escaped content.
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.
The optional application builder migration will now default to enabled and
recommended during the update process (`ng update`) for v19. The migration
is still optional and can be unselected if preferred when updating.
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.
