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
This is another feature that we mentioned in the Eliminate Render Blocking Requests RFC (#18730)
Inlining of critical CSS is turned off by default. To opt-in this feature set `inlineCritical` to `true`.
Example:
```json
"configurations": {
"production": {
"fileReplacements": [
{
"replace": "src/environments/environment.ts",
"with": "src/environments/environment.prod.ts"
}
],
"optimization": {
"styles": {
"minify": true,
"inlineCritical": true,
}
},
```
To learn more about critical CSS see;
https://web.dev/defer-non-critical-csshttps://web.dev/extract-critical-css/
In a future version of the Angular CLI `inlineCritical` will be enabled by default.
Closes: #17966Closes: #11395Closes: #19445
With this change we set the publicHost to `0.0.0.0:0`, when it's not provided.
This solved issues where previously the publicHost needed to be specified directly to get around `ERR_SSL_PROTOCOL_ERROR` error when proxing https -> http.
NB: this was also the behaviour in version 10 c252968225/packages/angular_devkit/build_angular/src/dev-server/index.ts (L170)Closes#19403
For the time being we cannot use the DOM lib because it conflicts with Node, In future when we remove `yarn admin build` we should have this as a seperate compilation unit.
The dev-server builder will now ask the user if an available port can be used when a specified port is already in use. If the user answers in the affirmative, an available port will be used instead. Otherwise, the serve operation will fail. If the terminal is not interactive (for example, CI), the serve operation will fail directly in the event of an already in use port.
