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.
When using Sass files with module import references in the esbuild-based browser application
builder, the module resolution attempts will now be cached in memory. This caching is only
local to each entry Sass file currently. However, this may be expanded to encompass all Sass
entries within a build in the future. In addition to caching the entire resolution attempt,
individual package root resolution is also cached for deep import attempts. This is useful
for packages (such as `@material/*`) which deep import to multiple different files in the
same package.
With this change combined with the previous lexer change, package managers (pnpm & Yarn PnP)
that require workarounds for functioning resolution will now perform at an equivalent level
to other package managers.
To correctly resolve a package based import reference in a Sass file with pnpm or Yarn PnP, the importer
file path must be known. Unfortunately, the Sass compiler does not provided the importer file to import plugins.
Previously to workaround this issue, all previously resolved stylesheets were tried as the importer path. This
allowed the stylesheets to be resolved but it also could cause a potentially large increase in build time due
to the amount of previous stylesheets that would need to be tried. To avoid the performance impact and to also
provide more accurate information regarding the importer file, a lexer is now used to extract import information
for a stylesheet and inject the importer file path into the specifier. This information is then extracted from the
import specifier during the Sass resolution process and allows the underlying package resolution access to a viable
location to resolve the package for all package managers. This information is currently limited to specifiers
referencing the `@angular` and `@material` package scopes but a comprehensive pre-resolution process may be added
in the future.
When optimizing a CommonJS exported enum, the build optimizer enum wrapping pass was previously
dropping the `exports` object assignment from the enum wrapper function call expression. This
would not occur with application code but is possible with library code that was built with
TypeScript and shipped as CommonJS.
Assuming the following TypeScript enum:
```
export enum ChangeDetectionStrategy {
OnPush = 0,
Default = 1,
}
```
TypeScript 5.1 will emit an exported enum for CommonJS as follows:
```
exports.ChangeDetectionStrategy = void 0;
var ChangeDetectionStrategy;
(function (ChangeDetectionStrategy) {
ChangeDetectionStrategy[ChangeDetectionStrategy["OnPush"] = 0] = "OnPush";
ChangeDetectionStrategy[ChangeDetectionStrategy["Default"] = 1] = "Default";
})(ChangeDetectionStrategy || (exports.ChangeDetectionStrategy = ChangeDetectionStrategy = {}));
```
The build optimizer would previously transform this into:
```
exports.ChangeDetectionStrategy = void 0;
var ChangeDetectionStrategy = /*#__PURE__*/ (() => {
ChangeDetectionStrategy = ChangeDetectionStrategy || {};
ChangeDetectionStrategy[(ChangeDetectionStrategy["OnPush"] = 5)] = "OnPush";
ChangeDetectionStrategy[(ChangeDetectionStrategy["Default"] = 8)] = "Default";
return ChangeDetectionStrategy;
})();
```
But this has a defect wherein the `exports` assignment is dropped. To rectify this situation, the build optimizer will now transform the code into:
```
exports.ChangeDetectionStrategy = void 0;
var ChangeDetectionStrategy = /*#__PURE__*/ (function (ChangeDetectionStrategy) {
ChangeDetectionStrategy[(ChangeDetectionStrategy["OnPush"] = 0)] = "OnPush";
ChangeDetectionStrategy[(ChangeDetectionStrategy["Default"] = 1)] = "Default";
return ChangeDetectionStrategy;
})(ChangeDetectionStrategy || (exports.ChangeDetectionStrategy = ChangeDetectionStrategy = {}))
```
This retains the `exports` assignment.
The esbuild plugin used within the esbuild-based browser application builder will now use the newly
introduced internal `supportJitMode` AOT compiler option to disable the emit of NgModule scope metadata
functions within the output code. This removes the need to perform an additional transformation of the
AOT compiler generated code to immediately remove the metadata. The Angular CLI neither previously nor currently
supports hybrid AOT/JIT mode. In the future if this support situation changes, additional behavior may
be added control the internal `supportJitMode` option.
When overriding module resolution on a TypeScript Host object, TypeScript will not
automatically create a resolution cache for the Host. Within the application build system
the TypeScript resolution is only overrided if file replacements are used. A resolution
cache is now manually created and added to the TypeScript Host when file replacements are
present.
This commit adds an `ssr` option to the application builder, this can be either a `boolean` or an `object` with an `entryPoint` property.
In the future, server bundles will only be emitted when the ssr option is truthy, as unlike SSR, SSG and AppShell do not require the server bundles to be written to disk.
The `browserslist` package is only needed in the custom Babel application preset if
the `supportedBrowsers` option is specified. This option is not used within the esbuild-
based browser application builder. The `browserslist` is now lazily imported only when
needed and avoids the overhead of loading browser support data when not needed by the build.
