The conversion of browserslist targets to esbuild targets has been updated to reflect additions
to esbuild. Additional browsers are now supported and the major/minor versions have been normalized.
The later of which ensures that `.0` major versions are not misinterpreted as ranges rather than
specific versions.
The Angular compiler is dependent on static fields being attached to
user-defined classes. e.g. `static ecmp = defineComponent`.
These static fields sometimes rely on variables from outside of the
class. e.g. the Angular compiler generates constants for content
projection that are then accessed in the static field initializer.
Surprisingly such access to these variables may break in Safari <=v15
when a page is loaded without devtools open. The bug (already solved in
v16 of Safari)- is very subtle, hard to re-reproduce but basically
variable scope tracking is broken. This bug is triggered by additional
parenthesis in the initializer expression. See:
https://bugs.webkit.org/show_bug.cgi?id=236843.
The TypeScript compiler may generate such additional parenthesis when
it tries to adjust the `this` context when invoking methods, such as for
defining animations in the `ecmp` definition.
More details can be found here:
https://github.com/angular/angular-cli/issues/24355#issuecomment-1333477033
To ensure Angular applications are not subject to this bug when
targeting Safari <=v15. v15 Safari, both for iOS and Mac is still part of
the default CLI browserslist with `last 2 Safari majors` (at time of
writing).
Note that it is important that the Babel plugin properly handles the
downleveling of static block-defined members. TypeScript will transform
static fields, like `static ecmp` into `static { this.ecmp = X }` when
`useDefineForClassFields = false` (which is the case for CLI apps). The
class properties plugin from Babel seems to handle this in an acceptable
way. Unlike actual static fields, Babel will not use helpers like
`defineProperty` for such extracted static blocks though. e.g.
See repro: https://gist.github.com/devversion/dec0dea26e348c509921bf62079b60be
```js
class Test {
x = true;
static b = true;
static {
this.a = true;
}
}
// into
class X {
constructor() {
_defineProperty(this, "x", true);
}
}
_defineProperty(X, "b", true);
X.a = true;
```
note that in practice TypeScript with `useDefineForClassFields = false`
will put non-static members into the constructor as normal assignments
regardless- so there would be no change by the Babel plugin.
Fixes#24355.
When optimization is enabled with the `@angular-devkit/build-angular:browser` builder, terser
is used as a second phase optimizer. The terser configuration previously set its `ecma` option
to `es2020` due to all officially supported browsers supporting the version. However, it is
possible to add browsers to the browserslist configuration that are not officially supported
that still may work but do not support es2020 syntax features. By setting the terser `ecma`
option to `es2015`, terser will not turn existing syntax into newer syntax features that might
be unsupported. Terser will also not downlevel any code based on this option.
Fixes#24347
Similar to errors messages we now hide webpack paths in warnings to reduce clutter.
Before
```
./src/styles.scss.webpack[javascript/auto]!=!./node_modules/css-loader/dist/cjs.js??ruleSet[1].rules[6].rules[0].oneOf[0].use[1]!./node_modules/postcss-loader/dist/cjs.js??ruleSet[1].rules[6].rules[0].oneOf[0].use[2]!./node_modules/resolve-url-loader/index.js??ruleSet[1].rules[6].rules[1].use[0]!./node_modules/sass-loader/dist/cjs.js??ruleSet[1].rules[6].rules[1].use[1]!./src/styles.scss?ngGlobalStyle - Warning: Module Warning (from ./node_modules/sass-loader/dist/cjs.js):
Deprecation $weight: Passing a number without unit % (60) is deprecated.
To preserve current behavior: $weight * 1%
More info: https://sass-lang.com/d/function-units
@material/slider/_slider-theme.scss 77:5 @use
node_modules/@angular/material/slider/_slider-theme.scss 3:1 @use
node_modules/@angular/material/core/density/private/_all-density.scss 25:1 @forward
@angular/_index.scss 18:1 @use
src/styles.scss 2:1 root stylesheet
```
After
```
./src/styles.scss - Warning: Module Warning (from ./node_modules/sass-loader/dist/cjs.js):
Deprecation $weight: Passing a number without unit % (60) is deprecated.
To preserve current behavior: $weight * 1%
More info: https://sass-lang.com/d/function-units
@material/slider/_slider-theme.scss 77:5 @use
node_modules/@angular/material/slider/_slider-theme.scss 3:1 @use
node_modules/@angular/material/core/density/private/_all-density.scss 25:1 @forward
@angular/_index.scss 18:1 @use
src/styles.scss 2:1 root stylesheet
```
When rebasing URLs found within Sass files (sass/scss), the previous regular expression
based searching has been replaced with a lexer that scans the Sass files for CSS url()
functions and extracts URL values. This change allows for more accurate discovery of
URLs as well as reducing the amount of content traversals per file. The lexer logic
is based on CSS Syntax Module Level 3 (https://www.w3.org/TR/css-syntax-3/).
The creation of the esbuild Angular plugin's Angular compilation has now been consolidated in a separate
class. This refactor reduces the amount of code within the plugin's main start function as well as centralizing
initialization, analysis, and source file emitting for the Angular build process.
When resolving Sass imports in the experimental esbuild-based browser application builder's Sass plugin,
previously imported modules are used as the base for resolution attempts to workaround the lack of the
importer file provided by Sass. When attempting to resolve a deep import into a package (including the
potential Sass index files), these previously imported modules also need to be checked. This is
particularly relevant when using the Yarn PnP or pnpm package managers which enforce strict dependency
resolution.
Fixes#24271
When using the experimental esbuild-based browser application builder, the JavaScript transformation
steps of the build process will now be performed within a worker pool to allow for the steps to be
executed in parallel when possible. This also moves the steps off of the main thread which provides
more time for the build orchestration and esbuild integration code to execute.
When performing Sass import resolution within the experimental esbuild-based browser application builder,
the directory cache entries will now be preprocessed during the first directory search operation. This
will allow a more streamlined search operation on later resolution attempts for the same directory.
The caching is still limited to sharing per render request but this change provides for cache entries
that can more easily be serialized and shared between workers in the future.
The creation of the esbuild Angular plugin's Angular compiler host has now been consolidated in a separate
function. This refactor reduces the amount of code within the plugin's main start function as well as centralizing
all initialization of the host into one location.
With this change we add the `vendorChunk` option in the server builder. This option should only be used in development as it is intended to be used to improve the incremental re-build time.
This improves the rebuild time as Webpack will have less modules to analyse during a change in the application. Below, we can see the impact this change has in a `ng new` application.
Without vendor chunking
```
$ ng run ssr-vendor:server:development --watch --no-vendor-chunk
Build at: 2022-11-14T08:42:27.089Z - Hash: 0325905b63e43ddb - Time: 15357ms
Build at: 2022-11-14T08:42:37.565Z - Hash: 05cb180a02524656 - Time: 2498ms
Build at: 2022-11-14T08:42:40.325Z - Hash: c5a6996ed1924088 - Time: 1862ms
Build at: 2022-11-14T08:42:43.043Z - Hash: 92ce99f38a769c19 - Time: 1516ms
```
With vendor chunking
```
$ ng run ssr-vendor:server:development --watch --vendor-chunk
Build at: 2022-11-14T08:43:13.631Z - Hash: 28bdfea879d01a31 - Time: 15561ms
Build at: 2022-11-14T08:43:19.396Z - Hash: cc95e2b6cb403111 - Time: 1705ms
Build at: 2022-11-14T08:43:21.296Z - Hash: 204138490668a16c - Time: 848ms
Build at: 2022-11-14T08:43:23.835Z - Hash: 4fa294b261917944 - Time: 824ms
```
When using the experimental esbuild-based browser application builder with the `fileReplacements` option,
TypeScript missing compilation file errors will now contain a note that the requested file was a
replacement for another file and show the path of the file.
When using the experimental esbuild-based browser application builder in watch mode, global stylesheets
configured with the `styles` option will now use the incremental rebuild mode of esbuild. This allows
for a reduction in processing when rebuilding the global styles. CSS stylesheets benefit the most currently.
Sass stylesheets will benefit more once preprocessor output caching is implemented.
The path adjustments and initial file logic for index file generation are now centralized in the esbuild
build helper function. This allows usage of the functionality in multiple areas of the build system.
With this change we add a warning to inform the users that sourcemaps are not generated when both styles sourcemaps and optimization are enabled. This is because component style sourcemaps are inline which would drastically increase the bundle size.
Closes#22834
When using the experimental esbuild-based browser application builder, `url()` functions within stylesheets
will no longer cause a build failure due to an attempted local file resolution of URLs that do not represent
on-disk resources. This includes absolute, protocol-relative, and root-relative URLs as well as SVG path
identifiers.
When using the experimental esbuild-based browser application builder with Sass and sourcemaps, the final
sourcemap for an input Sass stylesheet will now contain the original content for any `url` functions that
were rebased to support bundling. This required generating internal intermediate source maps for each imported
stylesheet that was modified with rebased URLs and then merging these intermediate source maps with the
final Sass generated source map. This process only occurs when stylesheet sourcemaps are enabled.
This commit fixes an issue where `@angular/platform-server/init` was added as an entry-point during the server build even when this was not installed.
Closes#24188
When using the experimental esbuild-based browser application builder with Sass, paths contained
in `url()` CSS functions will now be rebased to reflect their final location relative to the
output of the Sass compiler. This allows the bundler to locate and process any resource files
such as images or fonts used within the stylesheet.
The implementation of the rebasing functionality uses a series of custom Sass importers to
transform the input stylesheets (from import or use rules) when they are loaded from the
file system. However, for the Sass compiler to use the load functionality of an importer,
the `canonicalize` function (used to resolve an import) of the same importer must return
a resolved path to the requested stylesheet. To support this requirement, all stylesheet
resolution has been implemented in three new importers: relative, module, and load path.
An additional benefit of these resolvers is that they have been implemented to minimize the
volume of filesystem calls and also cache directory entry information (currently per request)
to further reduce file system access. The reduction in filesystem calls provides a small
performance benefit for projects containing a large amount of Sass file imports.
When using the experimental esbuild-based browser application builder, Sass module imports will
now resolve using esbuild's resolve methods. This allows for package.json exports and main fields
to be recognized when resolving an import or use rules in Sass files (scss or sass file extensions).
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`.
