Until we depend on `webpackStats` in the browser builder we should only included the required stats.
The below are the needed stats;
```
all: false,
colors: true,
hash: true,
timings: true,
chunks: true,
builtAt: true,
warnings: true,
errors: true,
assets: true,
ids: true,
entrypoints: true,
```
Since sass 1.33.0, an importer can determine whether it’s being called from an `@import` rule by checking `this.fromImport`. This API, is now being used by `sass-loader` version 12.
With this change we update to `webpack` to `5.38.1`, this also updates `webpack-sources` to `2.3.0`, The latter is causing OOM errors on our CI, but it in real projects the memory usage only increased by a small fraction. Also, the OOM errors don't manifest themselves when the entire test suit is run locally.
Therefore with this change we also disable sourcemap genertation for most of the browser builds to speed up the tests and reduce memery usage.
With this change we provide earlier feedback in the console during a build. The setup phase can take some times if the project has a large set of dependencies.
We also move several warnings in the dev-server to an earlier phase so that we don't clutter the progress indicator.
Closes#20957
The new `ngtools/webpack` option leverages the inline resource matching syntax combined with a custom loader instead of data URIs. This provides better resource path in loaders that do not yet fully support scheme-based resource requests.
Loading the postcss-preset-env plugin includes building a mapping of unsupported
browsers by feature, which is somewhat expensive. In large compilations, this mapping
would be recomputed for each postcss-loader instance, as the plugin was recreated
for each loader invocation. By extracting the plugin instance outside of the dynamic
plugin computation, this overhead is avoided.
Since #20518, the generation of the ServiceWorker configuration has been
broken on Windows. The reason is the use of `path.posix.*` methods on
non-POSIX paths, resulting in broken paths. I.e. we ended up with
something like the following:
```js
path.posix.relative('C:\\foo', 'C:\\foo\\bar/baz');
// Expected result: `bar/baz`
// Actual result: `../C:\\foo\\bar/baz`
```
This caused the config generator to fail to find any files and thus fail
to populate the config with cacheable assets.
This commit fixes this by using platform-specific `path.*` methods for
path manipulation and manually normalizing the path separators before
returning the results.
Fixes#20894
With this change we re-emit assets referenced in component stylesheets which where uneffected by the change that re-triggered a re-compilation.
Since we cache the the result of processed component CSS, during a re-compilation `postcss-cli-resources` plugin will not run which causes assets to be to emit. With this change we now cache the asset and re-emit them on every change.
Closes#20882
Since we rely on child compilations to compile components CSS, using the `parallel` option will cause a significant overhead because each compilation will need to spawn a worker, in this mode the worker limit is not be honored because `css-minimizer-webpack-plugin` spawn and calulators workers during the optimization phase of a compilation and not globally per instance hence causes OOM because a large number of workers to be spawned simultaneously.
Closes#20883
As reported in #20113, webpack triggers a Trusted Types violation when
lazy-loading is used. To mitigate that, enable webpack's Trusted Types
module (introduced in webpack/webpack#9856) using 'angular#bundler' as
the policy name.
The Worker constructor option for a transfer list is unfortunately not supported until Node.js 12.17. For Node.js versions prior to 12.17, a manual message post is now used to transfer the necessary initialization data to the Sass workers.
This reduce memory consumption during re-builds.
```
runtime.ba93f81591909b93394f.hot-update.js.map will be removed
styles.ba93f81591909b93394f.hot-update.js.map will be removed
runtime.ba93f81591909b93394f.hot-update.json will be removed
runtime.ba93f81591909b93394f.hot-update.js will be removed
styles.ba93f81591909b93394f.hot-update.js will be removed
```
See https://github.com/webpack/webpack/issues/12947#issuecomment-812108140 and https://github.com/webpack/webpack/issues/13127
A pool of Workers is now used to process Sass render requests. This change allows multiple synchronous render operations to occur at the same time. Sass synchronous render operations can be up to two times faster than the asynchronous variant. The benefit will be most pronounced in applications with large amounts of Sass stylesheets.
The dart-sass Sass implementation will now be executed in a separate worker thread. The wrapper worker implementation provides an interface that can be directly used by Webpack's `sass-loader`.
The worker implementation allows dart-sass to be executed in its synchronous mode which can be up to two times faster than its asynchronous mode. The worker thread also allows Webpack to continue other bundling tasks while the Sass stylesheets are being processed.
