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.
The `supports` query was added in version `4.13`, while `^4.9.1` does match this version is some cases an older version might be used to the presence of a lock file during the update which would cause the package not to be update.
Closes#24212
`minimatch` was unused within the `@angular-devkit/build-angular` package.
It is still used in a repository level development script and has been kept
in the root `package.json`.
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`.
