The `resetAngularServerApp` method was identical to `destroyAngularServerApp` and was mistakenly retained due to an incorrect merge. This commit removes the redundant method.
- Exposed several utility functions as private APIs to support the integration with the build system.
- Removed `isDevMode` and caching logic from `AngularAppEngine`. This was necessary to better handle updates when using Vite. Instead, `AngularServerApp` is now treated as a singleton to simplify management.
- Switched asset storage from an `Object` to a `Map` in the manifest for improved efficiency and consistency.
This refactor sets the groundwork for seamless wiring with the build system.
Now that style elements within templates are processed as inline component
styles, the style contents should only be considered CSS. This ensures
consistent behavior prior to when style elements were processed. It also ensures
that the styles will function as expected in JIT mode where template styles
cannot be preprocessed and must be written in a browser supported language.
If an application has JavaScript files that are sourced directly from disk,
the extraction would previously fail due to the i18n extractor only able
to access the in-memory generated JavaScript files. The extractor can now
access both memory and disk-based JavaScript files.
This enhancement eliminates the dependency on file extensions for server-side rendering (SSR) route handling, leveraging Angular's router configuration for more dynamic and flexible route determination. Additionally, configured redirectTo routes now correctly respond with a 302 redirect status.
The new router uses a radix tree for storing routes. This data structure allows for efficient prefix-based lookups and insertions, which is particularly crucial when dealing with nested and parameterized routes.
This change also lays the groundwork for potential future server-side routing configurations, further enhancing the capabilities of Angular's SSR functionality.
Previously, when a select or checkbox prompt failed validation, it was bypassed, preventing users from correcting their input. This commit ensures that when validation fails, the prompts are re-displayed, allowing users to make the necessary corrections. This improves the user experience and helps avoid unintended selections.
Closes#28189
This commit introduces the new hybrid rendering API for Angular's Server-Side Rendering (SSR). The API aims to enhance the flexibility of SSR as discussed in https://github.com/angular/angular/discussions/56785
- This API is currently not accessible.
- Additional work is required in the Angular CLI to:
- Wire up the manifest.
- Integrate other necessary components.
The Node.js inspector will now only be imported if SSR is enabled and
the `inspect` option is used. This prevents potential failures when a
custom Node.js binary build is used that has not enabled inspector usage.
While this is not common, loading the inspector on demand is a minimal
change that also avoids loading code that will not be used for the majority
of development server usage.
The internal "buildApplicationInternal" function is only used by several consumers that
require writing the output files to disk. One, `browser-esbuild`, directly writes
to the disk. The two experimental unit test builders also have unique requirements
and also directly write. This leaves only the main `application` builder that relies on the
internal file writing functionality of `buildApplicationInternal`. To avoid unneeded
logic for the other usages (`dev-server`, `extract-i18n`, unit testing, etc.), the
disk writing logic is now elevated to the `application` build itself. The internal
function will now always provide the output files within the result objects generated
from a successful build. This also removes the need for the other usages to specify
that files should not be written to disk.
If the TypeScript `incremental` option is explicitly set to `false`, the
`application` builder will no longer attempt to enable and use incremental
compilation mode via stored TypeScript build file information. This prevents
an potential build time error that would otherwise occur due to the `tsBuildInfoFile`
option being set without the `incremental` option.
Behavior remains the same if the option is not present or set to `true`.
This addresses a bug where `@import url()` statements with remote CSS files (ending in .css) caused build errors when Tailwind was present. The issue arised from incorrect handling of remote URLs by the stylesheet plugin, which treated them as local files. This fix ensures proper handling of remote CSS imports.
Closes#28113
The Sass rebasing lexer was incorrectly checking for a comma in certain
cases previously. This has now been corrected and url usage that immediately
follows a comma within a rule will now be extracted as expected.
The application builder now provides structured output types to its internal
consumers. The architect builders themselves and the programmatic API is
not changed. These output result types allow for the development server to
receive additional information regarding the build and update the active
browser appropriately. This functionality is not yet implemented but the
additional result types provide the base infrastructure to enable future
features. The result types also allow for reduced complexity inside other
builders such as i18n extraction and the browser compatibility builder.
The usage is not yet fully optimized and will be refined in future changes.
When adjusting URLs to support explicit external dependencies when using Vite,
the workaround will now account for the presence of a base HREF value within
the specifier. Vite will automatically add the base HREF as a prefix to the
path when specified. This previously resulted in invalid specifiers due to
the partial removal of the Vite specific `@id` path prefix.
When using the application builder, a `loader` import attribute is now available
for use with import statements and expressions. The presence of the import
attribute takes precedence over all other loading behavior including JS/TS and
any `loader` build option values. This allows per file control over loading
behavior. For general loading for all files of an otherwise unsupported file
type, the `loader` build option is recommended.
For the import attribute, the following loader values are supported:
* `text` - inlines the content as a string
* `binary` - inlines the content as a Uint8Array
* `file` - emits the file and provides the runtime location of the file
Unfortunately, at this time, TypeScript does not support type definitions
that are based on import attribute values. The use of `@ts-expect-error`
or the use of individual type definition files (assuming the file is only
imported with the same loader attribute) is currently required.
Additionally, the TypeScript `module` option must be set to `esnext` to
allow TypeScript to successfully build the application code.
As an example, an SVG file can be imported as text via:
```
// @ts-expect-error TypeScript cannot provide types based on attributes yet
import contents from './some-file.svg' with { loader: 'text' };
```
When using the development server and a file that is referenced from a Node.js
package with a loader attribute, the package must be excluded from prebundling
via the development server `prebundle` option. This does not apply to relative
file references.
When the sourceMaps are enabled they are generating some files that are computed by the budget stats. Now the method `generateBudgetStats` skip when the file is undefined.
The `ansi-color` and `ora` dependencies have been replaced with `listr2`.
This package provides both color and spinner capabilities and further
reduces the dependency count. This also aligns the dependencies with
the `@angular/cli` package with already uses `listr2`. The spinner also
now will not overwrite console output that happens to be written while
the spinner is active. Instead, the output will be written after the
spinner task is complete.
The schematics encapsulation process now uses a similar wrapping setup to
Node.js itself. This removes some custom code and also provides a more
comprehensive global object which should provide improved compatibility
for third-party packages used within schematics.
