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.
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.
