BREAKING CHANGE:
The dev-server now uses WebSockets to communicate changes to the browser during HMR and live-reloaded. If during your development you are using a proxy you will need to enable proxying of WebSockets.
The `no-useless-escape` eslint rule has now been enabled which removes unneeded characters and complexity from string literals and regular expressions. All files that were in violation of this rule have also been corrected.
`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.
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.
Not removing inline sourcemaps when vendor sourcemaps is disabled causes an issue during the JS optimization sourcemap merging phase.
```
Optimization error [936.cf7797927c7f989bd40d.js]: Error: Transformation map 1 must have exactly one source file.
```
When vendor sourcemaps is disabled we are not interested into the said sourcemaps so now we remove the inline sourcemap.
Closes#21508
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.
The Webpack configuration setup previously walked up the directory structure to find all `node_modules` directories and then pass this list to Webpack's `resolverLoader.modules` option. This was previously done to ensure that hoisted packages were properly resolved. However, all loader paths are now fully resolved prior to being added to the Webpack configuration. Since loader paths will now be absolute, Webpack no longer needs to resolve them which makes the resolve settings no longer necessary.
BREAKING CHANGE:
The automatic inclusion of Angular-required ES2015 polyfills to support ES5 browsers has been removed. Previously when targetting ES5 within the application's TypeScript configuration or listing an ES5 requiring browser in the browserslist file, Angular-required polyfills were included in the built application. However, with Angular no longer supporting IE11, there are now no browsers officially supported by Angular that would require these polyfills. As a result, the automatic inclusion of these ES2015 polyfills has been removed. Any polyfills manually added to an application's code are not affected by this change.
BREAKING CHANGE:
Differential loading support has been removed. With Angular no longer supporting IE11, there are now no browsers officially supported by Angular that require ES5 code. As a result, differential loading's functionality for creating and conditionally loading ES5 and ES2015+ variants of an application is no longer required.
This change fixes `NG_PERSISTENT_BUILD_CACHE` sometimes creating cache
entries that live outside of the cache directory by using a hex encoding
rather than a base64 encoding. This error is caused because the base64
alphabet includes `/`. According to the webpack documentation [1] the
default `cacheLocation` is:
path.resolve(cache.cacheDirectory, cache.name)
Which means cache names with a leading `/` would remove the
`cacheDirectory` altogether.
[1]: https://webpack.js.org/configuration/other-options/#cachecachelocation
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 `esModuleInterop` option is recommended to be enable by TypeScript and corrects several assumptions TypeScript would otherwise make when importing CommonJS files.
This option change helps ensure compatibility as packages move towards ESM.
Reference: https://www.typescriptlang.org/tsconfig#esModuleInterop
With this change we enable Webpack's filesystem cache, this important because `terser-webpack-plugin`, `css-minimizer-webpack-plugin` and `copy-webpack-plugin` all use Webpacks' caching API to avoid additional processing during the 2nd cold build.
This changes causes `node_modules` to be treated as immutable. Webpack will avoid hashing and timestamping them, assume the version is unique and will use it as a snapshot.
To opt-in using the experimental persistent build cache use the`NG_PERSISTENT_BUILD_CACHE` environment variable.
```
NG_PERSISTENT_BUILD_CACHE=1 ng serve
```
The new babel-based build optimizer passes are now enabled when targetting ES2015 and higher. ES5 targets will currently continue to use the previous build optimizer. ES5 support will require additional refactoring of the downlevelling process as the new build optimizer passes are designed for ES2015 code.
With the recent changes in https://github.com/angular/angular-cli/pull/20960 we moved the spinner to be started outside of the progress callback, this causes a side-effect that after `succeed` is called the spinner will stop reporting progress unless it is started again.
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
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
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
All TypeScript files have been updated to pass the new eslint-based linting checks. eslint compatible disabling comments have also been added in place of the previous tslint comments.
The GC caching mode will remove any unused cache entries after each rebuild. This prevents old modules from being retained indefinitely during long-lived development sessions.
The Webpack 5 automatic public path support can cause an incorrect public path to be used to load assets and lazy loaded routes. The current logic relies on the last script element found at runtime in the application's index HTML which may not be related to the application scripts. Now if a `deployUrl` is not specified, the Webpack `publicPath` option is defaulted to an empty string which provides equivalent behavior to Webpack 4.
In some scenarios in Webpack 5 percentage goes from 1 back to 0.99, ex: 0.99 -> 1 -> 0.99 -> 1. This causes the "complete" message to be displayed multiple times.
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), ...)`
If an error occurs during a build, it is possible that the output path directory may not be present and then cause the stats JSON file write to fail.
Fixes: #20349
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.
