The development server proxy configuration file for Webpack supports a `pathRewrite` field that is
not directly supported by the underlying Vite development server when using the application or esbuild-
browser builders. To provide equivalent support, especially for JSON file-based proxy configurations,
the `pathRewrite` field is now converted internally to a proxy `rewrite` function.
When using the Vite-based development server and a custom `index` build option (not `index.html`),
the custom index path will now be used as the root of the development server. This mimics the behavior
of the Webpack-based development server.
The JavaScript generated for the published packages is now using ES2022.
This removes additional downleveling of code that was previously necessary
to use newer features.
The minimum Node.js version of 18.13 provides support for the needed features.
While this change does require a patch to `@bazel/concatjs` to allow the target
to be set to `ES2022`, this patch is now already required by the migration of
the universal repository into the CLI repository.
By setting up a single instance of the `JavaTransformer`, the Vite-based development server will now
have a fixed and controllable number of worker threads available to process prebundling requests. This
avoids a potentially large number of initial worker threads when a new application with a large number
of dependencies is first used with the development server. This is particularly beneficial for web
container setups which may not be able to efficiently handle the number of workers.
Updates the logic that elides `setClassMetadata` calls to also elide `setClassMetadataAsync`. The latter will be emitted when the component uses the new `defer` block syntax.
Updates the logic for removing Angular metadata and pure top-level functions to account for arrow-function-based IIFEs. Currently Angular doesn't generate arrow functions, but it's being explored in https://github.com/angular/angular/pull/51637.
The esbuild-based application builder will now access the project level i18n configuration
as well as the builder `localize`, `duplicateTranslationBehavior`, and `missingTranslationBehavior`
options to construct a full, normalized i18n option structure.
These options are not yet used by the builder but they are now available to access as future
work incrementally adds i18n support.
This removes the util function for express, instead the "CommonEngine" is called directly infuture before this package is final we might rename the "CommonEngine" to something else.
The `ng extract-i18n` command now supports using either the developer preview esbuild-based browser
or application builders. Support for the existing Webpack-based build system has been maintained.
The extraction process will now build the application based on the build target defined builder in
the case of either `@angular-devkit/build-angular:browser-esbuild` and `@angular-devkit/build-angular:application`.
In the case of the application builder, SSR output code generation is disabled to prevent duplicate messages
for the same underlying source code.
BREAKING CHANGE: Node.js v16 support has been removed
Node.js v16 is planned to be End-of-Life on 2023-09-11. Angular will stop supporting Node.js v16 in Angular v17.
For Node.js release schedule details, please see: https://github.com/nodejs/release#release-schedule
Version 0.19 of esbuild added the ability to consider tsconfig path mappings when using the
external packages build option. This addition allows the Angular build system to remove a
resolve plugin that previously was used to workaround this limitation. Removal of the plugin
may also provide improved rebuild performance when used with the development server as many
of the JavaScript resolution attempts will no longer need to be handled by the now removed
plugin.
When using the new developer preview application build system, Sass import/use usage that specifies
a package is adjusted to contain the resolve directory to workaround Sass import plugin limitations.
This resolve directory is now encoded to prevent the new specifier from looking like a URL with a
scheme to the Sass compiler. This can occur on Windows when a drive letter is present (`C:\`).
When using the esbuild-based browser application builder, TypeScript diagnostics are now converted
into esbuild messages within the compilation base class instead of the plugin. This helps further
isolate the TypeScript details within the compilation classes. Additionally, this provides diagnostic
objects that can be more easily serialized earlier in the build process.
magic-string 0.30.2 introduced [the `boundary` strategy][1] for its high-resolution
source map mode, reducing the number of source map segments to align with word
boundaries instead of having a segment per character.
[1]: https://github.com/Rich-Harris/magic-string/pull/255
The `extract-i18n` builder code has been restructured in a similar fashion to the `dev-server` builder.
This refactor provides the groundwork to add support for the `application` and `browser-esbuild` builders
during message extraction.
The webpack related logic has been split into a separate file and is dynamically imported when needed.
Additionally the options processing has been moved to a separate file and the `index.ts` now only exports
instead of previously containing most of the builder logic.
These changes revert the performance improvement from e88aea65bd and add a test. The problem with the previous approach is that it assumes that a `link` tag processed by Critters will be preceded by a `style` tag that was inserted by Critters. This assumption might not necessarily be true if Critters is unable to resolve the content of the linked styles. Furthermore, I'm not sure if we need to optimize this code path to begin with, because it only does a shallow traversal of the `head` tag which is generally fast and is unlikely to have many direct descendants.
Fixes#25419.
The underlying development server (Vite) for the application build system updated
its static file serving dependencies which resulted in the `@fs` special file URLs
supported by Vite to have a different format. Previously, the paths were encoded
using `encodeURIComponent` but are now use `encodeURI`. The development server
integration with Vite will now use the matching encoding to allow build defined
assets to be correctly served.
