BREAKING CHANGE:
The deprecated `showCircularDependencies` browser and server builder option has been removed. The recommended method to detect circular dependencies in project code is to use either a lint rule or other external tools.
The `proxyConfig` option for the `dev-server` builder now supports JSON files containing comments and trailing commas.
Several additional tests regarding the use of ESM and CommonJS JavaScript configuration files were also added to reduce the likelihood of future regressions.
Closes: #21862
With this change we replace `@jsdevtools/coverage-istanbul-loader` webpack loader with [`babel-plugin-istanbul`](https://github.com/istanbuljs/babel-plugin-istanbul) which is an official Babel plugin by the istanbuljs team.
Previously, when code coverage was enabled we had multiple Babel runs on the same file. This is because istanbuljs' `instrumentSync` and `instrument` APIs which are used by the Webpack plugin invokes Babel directly 66bc39b3c7/packages/istanbul-lib-instrument/src/instrumenter.js (L98)
By using the babel plugin directly, we avoid this which also improves the sourcemaps correctness and test performance.
Closes#22010
Persistent disk build cache is now enabled by default. A number of options have been added to allow fine tuning of the cache.
The options can be configuration in `cli.cache` section in the `angular.json` as shown below.
- `enabled`: Configure whether disk caching is enabled. Defaults to `true`
- `environment`: Configure in which environment disk cache is enabled. Valid values `ci`, `local` or `all`. Defaults to: `local`
- `path`: cache base path. Defaults to `.angular/cache`
DEPRECATED: `NG_BUILD_CACHE` environment variable option will be removed in the next major version. Configure `cli.cache` in the workspace configuration instead.
BREAKING CHANGE: `NG_PERSISTENT_BUILD_CACHE` environment variable option no longer have effect. Configure `cli.cache` in the workspace configuration instead.
```json
{
"$schema": "./node_modules/@angular/cli/lib/config/schema.json",
"version": 1,
"cli": {
"cache": {
"enabled": true,
"path": ".custom-cache-path",
"environment": "all"
}
}
...
}
```
In the event that the Angular CLI is executed on a platform that does not yet have native support for esbuild, the WASM-based variant of esbuild will now be used. If the first attempt to optimize a file fails to execute the native variant of esbuild, future executions will instead use the WASM-based variant instead which will execute regardless of the native platform. The WASM-based variant, unfortunately, can be significantly slower than the native version (some cases can be several times slower). For install time concerns regarding the esbuild post-install step, esbuild is now listed as an optional dependency which will allow the post-install step to fail but allow the full npm install to pass. This install scenario should only occur in the event that the esbuild native binary cannot be installed or is otherwise unavailable.
rules_nodejs 4 requires that a package_name property be specified within a ts_library rule for the output to be linked into the package repository. Failing to add the property can cause test failures due to unresolved packages.
`esbuild` and `terser` are now used to optimize global scripts in addition to the previous performance enhancement of optimizing application bundles. This change removes the need for the `terser-webpack-plugin` as a direct dependency and provides further production build time improvements for applications which use global scripts (`scripts` option in the `angular.json` file).
Since `esbuild` does not support optimizing a script with ES2015+ syntax when targetting ES5, the JavaScript optimizer will fallback to only using terser in the event that such a situation occurs. This will only happen if ES5 is the output target for an application and a global script contains ES2015+ syntax. In that case, the global script is technically already invalid for the target environment and may fail at runtime but this is and has been considered a configuration issue. Global scripts must be compatible with the target environment/browsers.
Esbuild now support CSS sourcemaps which now makes it possible to be used to optimize global CSS.
With this change we also reduce the amount of dependencies by removing `css-minimizer-webpack-plugin` which brings in a number of transitive depedencies which we no longer use.
The legacy standalone build optimizer was still used when targetting ES5 due to the new babel-based build optimizer only supporting the analysis of ES2015+ code. Mainly due to the presence of native classes, the new build optimizer is faster and significantly less complex. To fully remove the legacy build optimizer, ES5 downleveling of application code is now also performed by babel when the TypeScript configuration specifies an ES5 target. TypeScript will now internally emit ES2015 in this configuration and ES2015 code will be used as the input to the remainder of the build pipeline. This has been the behavior for third-party packages and now all code will be consistently downleveled to ES5 using the same tooling.
All Angular builders are now located within one subdirectory of the `src` directory. This organization provides better discovery of the builders and will allow builder specific code to be stored in a single area.
BREAKING CHANGE:
With this change we removed several deprecated builder options
- `extractCss` has been removed from the browser builder. CSS is now always extracted.
- `servePathDefaultWarning` and `hmrWarning` have been removed from the dev-server builder. These options had no effect.
The dev-infra tooling now directly provides public API change testing capabilities that leverage the `api-extractor` utility. These new testing capabilities are shared with framework and components.
`ts-api-guardian` has been removed as a dependency as a result.
With Webpack 5, the `raw-loader` is no longer needed and its functionality is provided via configuration options within the Webpack configuration via asset modules. Asset modules (https://webpack.js.org/guides/asset-modules/) provide a built-in way to provide `raw-loader`, `url-loader`, and `file-loader` functionality without additional dependencies.
The `@ampproject/remapping` package is now used for source map processing instead of Webpack for differential loading and i18n processing. This dependency is already used within the recently added JavaScript optimizer refactoring and reduces the amount of code that needs to be loaded into each worker to support differential loading sourcemaps.
The worker pool for differential loading and i18n processing is now managed by the `piscina` dependency. This dependency is already used within the recently added JavaScript optimizer refactoring and reduces both the number of direct dependencies and amount of code to setup the worker pools.
The javascript optimization pipeline is now a two-phase process. `esbuild` is used in the first phase to remove the majority of the unused code and shorten identifiers in each output bundle script. `esbuild` can accomplish this in a fraction of the time that `terser` previously required. However, `esbuild` does not yet implement all of the optimizations that `terser` performs. As a result, `terser` is used as a second phase to further optimize and reduce the size of the output bundle scripts. Since `terser` is operating on a smaller input size, the time required for `terser` to complete is significantly reduced. To further improve performance when source maps are enabled, the source map merging is now performed within the optimization workers. A maximum of four (4) optimization workers are currently used and this value can be adjusted via the `NG_BUILD_MAX_WORKERS` environment variable.
The build optimizer passes that are still relevant for Ivy are now implemented as babel plugins. Using babel has several advantages. The `babel-loader` is already present within the build pipeline and many packages will already need to be processed by it. The `babel-loader` also provides the necessary infrastructure to setup babel and link it to the Webpack build system. This removes the need for the infrastructure code within the build optimizer loader and reduces the build optimizer to only a set of transformation plugins for babel to consume. The babel plugin architecture also allows for less code to represent similar transformations and provides a variety of helper utilities which further reduces the amount code needed.
The passes are now implemented to be safer when transforming code. Enum values which contain potential side effects are also no longer altered. Enums are wrapped in less destructive manner which reduces the likelihood of incorrectly emitting the transformed enum. Class static fields which contain potential side effects are no longer wrapped in pure annotated IIFEs. Known safe Angular static fields are also wrapped and Angular static fields which are not required in production code are also dropped.
The conversion of the passes not only reduces the amount of code to maintain but also provides a noticeable performance improvement. Initial tests of a production build of AIO resulted in a ~10% total build time reduction.
Closes#12160
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.
With this change Webpack 5 is now used by the Angular tooling to build applications. Webpack 4 usage and support has been removed.
No project level configuration changes are required to take advantage of the upgraded Webpack version when using the official Angular builders.
Custom builders based on this package that use the experimental programmatic APIs may need to be updated to become compatible with Webpack 5.
BREAKING CHANGE: Webpack 5 lazy loaded file name changes
Webpack 5 generates similar but differently named files for lazy loaded JavaScript files in development configurations (when the `namedChunks` option is enabled).
For the majority of users this change should have no effect on the application and/or build process. Production builds should also not be affected as the `namedChunks` option is disabled by default in production configurations.
However, if a project's post-build process makes assumptions as to the file names then adjustments may need to be made to account for the new naming paradigm.
Such post-build processes could include custom file transformations after the build, integration into service-side frameworks, or deployment procedures.
Example development file name change: `lazy-lazy-module.js` --> `src_app_lazy_lazy_module_ts.js`
BREAKING CHANGE: Webpack 5 web worker support
Webpack 5 now includes web worker support. However, the structure of the URL within the `Worker` constructor must be in a specific format that differs from the current requirement.
Web worker usage should be updated as shown below (where `./app.worker` should be replaced with the actual worker name):
Before: `new Worker('./app.worker', ...)`
After: `new Worker(new URL('./app.worker', import.meta.url), ...)`
With recent improvements to the dev-server builder unit tests, additional parallel testing should now be possible.
The unused `express` dependencies are also removed.
When using the `statsJson` browser builder option, the resulting JSON data is now streamed into a file instead of written in one large block. This mitigates crashes due to the generated string exceeded the Node.js limit.
The plugin was only used when the `NG_BUILD_PROFILING` environment variable was used. The environment variable also enabled the Webpack builtin `ProfilingPlugin` which is retained.
The builtin plugin provides a chrome events JSON output which can be loaded in Chrome DevTools and allows for graphical timeline views of the build.
The `speed-measure-plugin` is also currently incompatible with Webpack 5 which would prevent the CLI profiling support from working with Webpack 5.
With this change we add `postcss-preset-env` with stage 3 features. This stage includes support for:
- all property
- break properties
- custom properties
- font-variant property
- gap properties
- media query ranges
See https://preset-env.cssdb.org/features#stage-3
The experimental rollup pass has significant issues with the new Ivy webpack plugin. It also, didn't produce as well as we hoped in real world scenarios infact in many cases this caused build to fail.
REAKING CHANGE:
The experimental rollup pass `--experimental-rollup-pass` option has been removed.
Closes#15836
`file-loader` resolves `import/require()` on a file into a url. This is non standard, undocumented, unsupported Webpack specific functionality. This was introduced in the Angular CLI before `postcss-cli-resources` existed and was never removed.
Using `file-loader` and `postcss-cli-resources` are no longer needed with Webpack 5, because of the introduction of [Assets Modules](https://webpack.js.org/guides/asset-modules/).
BREAKING CHANGE:
The unsupported/undocumented, Webpack specific functionality to `import`/`require()` a non-module file has been removed.
Before
```js
import img from './images/asset.png';
```
After
```html
<img src="images/asset.png">
```
With this change users can now their proxy server via the `HTTPS_PROXY` environment variable. The specified proxy will be used when making requests to inline fonts.
Closes#19401
