`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`.
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.
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.
The experimental esbuild-based browser application builder now contains initial support for
watching input files and rebuilding the application via the `--watch` option. This initial
implemention is not yet optimized for incremental rebuilds and will perform a full rebuild
upon detection of a change. Incremental rebuild support will be added in followup changes
and will significantly improve the rebuild speed.
The `chokidar` npm package is used to perform the file watching which allows for native file-
system event based watching. Polling is also support via the `--poll` option for environments
that require it.
The usage of Stylus in the CLI is minimal and this package never reached version 1.
BREAKING CHANGE:
Deprecated support for Stylus has been removed. The Stylus package has never reached a stable version and its usage in the Angular CLI is minimal. It's recommended to migrate to another CSS preprocessor that the Angular CLI supports.
This dependency is only used to valid that node packages are resolved correctly.
With this change we mock the structure of font-awesome to avoid having to install it.
The dev-infra build tooling is now decoupled from `ng-dev`. This will
make it easier to update `ng-dev` without necessarily needing to upgrade
the whole build system, Bazel etc. This is useful when e.g. new release
tool features have been added and should also be ported to active LTS
branches.
This commit add a new `externalDependencies` option to the experimental browser builder.
Dependencies listed in this option will not be included in the final bundle, instead the user would need to provide them at runtime using import maps or another method.
Closes#23322
Since Angular 8, the CLI has transformed decorator metadata to a form that can be used by the Angular dependency injector without the TDZ limitations of Typescript's decorator metadata emit feature.
As a result, a JIT application compiled with the CLI no longer requires the reflect metadata polyfill that was provided by `core-js`.
This polyfill was also the last remaining usage of the `core-js` package within `@angular-devkit/build-angular` which allows the `core-js` package to also be removed.
Refs: https://github.com/angular/angular-cli/pull/14473 & https://github.com/angular/angular/pull/37382
BREAKING CHANGE: Reflect metadata polyfill is no longer automatically provided in JIT mode
Reflect metadata support is not required by Angular in JIT applications compiled by the CLI.
Applications built in AOT mode did not and will continue to not provide the polyfill.
For the majority of applications, the reflect metadata polyfill removal should have no effect.
However, if an application uses JIT mode and also uses the previously polyfilled reflect metadata JavaScript APIs, the polyfill will need to be manually added to the application after updating.
To replicate the previous behavior, the `core-js` package should be manually installed and the `import 'core-js/proposals/reflect-metadata';` statement should be added to the application's `polyfills.ts` file.
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.
