V8 currently has a performance defect involving object spread operations that can cause degradation
in runtime performance. By specifically not supporting the object spread language feature when using
the esbuild-based browser application builder, a downlevel form will be used instead which provides a
workaround for the performance issue. The downlevel form can cause up to a 600 byte increase in file
size if an object spread operation would otherwise be present in an output file.
For more details: https://bugs.chromium.org/p/v8/issues/detail?id=11536
When using the experimental esbuild-based browser application builder, Sass stylesheets will
now be processed using a worker pool that is currently also used by the default Webpack-based
builder. This allows up to four stylesheets to be processed in parallel and keeps the main thread
available for other build tasks. On projects with a large amount of Sass stylesheets, this change
provided up to a 25% improvement in build times based on initial testing.
When using the experimental esbuild-based browser application builder in watch mode, the file watcher will now
wait 250ms from a reported file event before triggering a rebuild. The change allows the rebuild to better
capture groups of file changes. This can happen when using an IDE while editing multiple files and would otherwise
result in multiple rebuilds where a single rebuild would be ideal.
When using the experimental esbuild-based browser application builder in watch mode,
the base cache path defined within the `angular.json` file will now be ignored when
detecting file changes. While the builder currently does not persist cache to disk, it
may in the future and other builders may currently be run in parallel.
The dev-server builder currently does not support the experimental esbuild-based browser application
builder and will use the Webpack-based builder instead. To better inform users of this behavior, a
warning is now issued upon executing the dev-server.
The experimental esbuild-based browser application builder will now avoid trying to query the Angular
Compiler for template diagnostics when a TypeScript source file is a declaration file (`.d.ts`). This
avoids the overhead of the in-memory diagnostics caching logic as well as any Angular Compiler logic
to determine if the file has any template diagnostics.
When the `NG_BUILD_DEBUG_PERF` environment variable is used to debug performance of the experimental
esbuild-based browser application builder, additional information will be logged for cumulative
profiling actions. This includes the count, minimum, maximum, and average.
To further improve incremental rebuild performance of the experimental esbuild-based browser
application builder, the output of the TypeScript file loader within the Angular compiler plugin
are now cached in memory by the input file name and invalidated via the file watching events.
This allows an additional TypeScript emit including the associated transformations per input file
to be avoided if the file has not changed or has not been affected by other files within the
TypeScript program.
Enhanced resolver is unable to resolve transitive dependencies in Sass when using Yarn PNP. The main reason for this is that Sass doesn't provide context on which file is requesting the module. See: sass/sass#3247.
As a workaround for this we store previously resolved paths and when a new request comes in we try to resolve this from the previously resolved files if we are unable to resolve the request from the workspace root.
The `postcss-imports` package was previously used to support `@import` within CSS files. Unfortunately,
the package does not account for `package.json` exports fields. This prevents imports defined within that
field from working when used within a build. The `css-loader` package does provide this functionality and
is now used to provide support for CSS `@import` instead of `postcss-imports`. This change does not affect
preprocessors that provide their own import behavior.
Karma is an optional peer dependency, but with the recent changes we broke this as we imported karma outside of the execution method, which made this package to be always imported even when the Karma builder was not invoked.
When using the experimental esbuild-based browser application builder in watch mode, the in-memory
incremental caching will now use Uint8Arrays where possible to limit the amount of encoding needed
when passing data to esbuild. When passing a string to esbuild, it must encode the string prior to
sending it. By providing the pre-encoded data from the in-memory cache, this step can be skipped
for rebuilds of input files that have not changed.
Some libraries ship spec in node_modules which might result errors such
```
./node_modules/comment-parser/tests/unit/spacer-description-joiner.spec.ts - Error: Module build failed (from ./node_modules/@ngtools/webpack/src/ivy/index.js):
Error: /Users/kkostadinov/Projects/material.angular.io/node_modules/comment-parser/tests/unit/spacer-description-joiner.spec.ts is missing from the TypeScript compilation. Please make sure it is in your tsconfig via the 'files' or 'include' property.
```
This changes removes the need to import `@angular/platform-server/init` in the `main.server.ts` instead we now include this as an entry-point when we are bundling as server bundle.
With this change we remove the need to include the `@angular/localize/init` package as polyfills in `polyfills.ts`, `angular.json` and `main.server.ts`.
Instead when `@angular/localize/init` is included in the TypeScript `types` we add this as entry-point. The `@angular/localize/init` will be added as a parts of the `types` array in a seperate PR to address https://github.com/angular/angular/issues/47677 which is caused by the fact that `@angular/localize/init` types are no longer imported when `@angular/localize/init` is added as a polyfill in `angular.json`.
When using the experimental esbuild-based browser application builder, the Angular diagnostic analysis performed
per rebuild is now reduced to only the affected files for that rebuild. A rebuild will now query the TypeScript
compiler and the Angular compiler to determine the list of potentially affected files. The Angular compiler will
then only be queried for diagnostics for this set of affected files instead of the entirety of the program.
The Sass preprocessor's modern API will generate absolute file URLs for the `sources` field of generated
sourcemaps. These URLs will not be properly processed by esbuild and will not be correctly adjusted to be
relative to the workspace root directory for the built application. To correct this behavior, the Sass
generated sourcemaps are now adjusted to remove the `file:` protocol prefix and to make each path relative
to its input file. This allows esbuild to properly resolve and process the paths.
Prior to this change non relative partial files were not resolved properly. Example we did not try to resolve `@material/button/button` as `@material/button/_button` which caused the compilation to fail.
All analytics is now in the @angular/cli package
BREAKING CHANGE: analytics APIs have been removed without replacement from `@angular-devkit/core` and `@angular-devkit/architect`.
This change updates the analytics collector collector to use GA4 instead of UA. The motivation behind this change is that UA will stop collecting data in 2023.
BREAKING CHANGE:
`analyticsSharing` option in the global angular configuration has been
removed without replacement. This option was used to configure the Angular CLI to access to your own users' CLI usage data.
If this option is used, it can be removed using `ng config --global cli.analyticsSharing undefined`.
When using the experimental esbuild-based browser application builder, initial debug performance profiling
information can now be output to the console by using the `NG_BUILD_DEBUG_PERF` environment variable. When
enabled, duration information for elements of the Angular build pipeline will be shown on the console.
Certain elements marked with an asterisk postfix represent the total parallel execution time and will
not correlate directly to the total build time. This information is useful for both experimentation with
build process improvements as well as diagnosing slow builds.
When generating an app-shell via the app-shell builder, the server application rendering
will now take place within a Node.js Worker. Since the rendering requires the presence of
Zone.js, this change allows for the Zone.js patching to be isolated from the remainder
of the builder and Angular CLI code. This prevents Zone.js from persisting past the needed
render operation. This also allows for a workaround to a Zone.js/Node.js v18 problem where
the TypeScript dynamic import workaround involving the Function constructor to ensure a native
dynamic import expression will cause a failure when running on Node.js v18.10.
Update the build time calculation for the experimental esbuild-based browser application builder to
use the `process.hrtime` time source. The high resolution time provides a more accurate time source
and allows for nanosecond level timings if needed. Currently the console output is rounded to the
nearest millisecond. Future performance monitoring capabilities may leverage the more fine-grained
values.
To further improve incremental rebuild performance of the experimental esbuild-based browser
application builder, the output of JS file babel transformations are now cached in memory by
the input file name and invalidated via the file watching events. This allows an additional
file read per JS input file to be avoided if the file has not changed. Previously the content
of the JS input file was used as the basis of the cache key for the transformation output which
necessitated reading the file. With the file change information available, the content based method
is no longer necessary.
The experimental esbuild-based browser application builder will now support incremental JavaScript
bundling when run in watch mode via the `watch` option. This initial implementation integrates the
esbuild incremental rebuild functionality. TypeScript source file caching has also been added to
improve the rebuild initialization time for the TypeScript and Angular compilation steps.
This initial support is not yet fully optimized and additional work is planned to further improve
the rebuild performance.
A single options object is now used within the experimental esbuild-based browser application builder.
This removes the need to pass around two different options objects with potentially overlapping properties
throughout the build process.
The initial global stylesheet, file replacement, index HTML, and service worker option analysis and cleanup has
now been moved into the `normalizeOptions` helper for the esbuild-based browser application builder. This better
organizes the option related setup steps as well as reduces the amount of code in the main builder source file.
