Previously, we introduced the `ngResource` query to Angular component resources we now use it with `resourceQuery` to differentiate between global and components styles, since in some cases while unlikely a file can be used as a component and global style.
Closes#7245
* fix(@angular-devkit/build-angular): correctly extract messages when using cached build
Extracted messages are not part of Webpack pipeline and hence they cannot be retrieved from cache. Therefore, we need to mark the extraction loader as non cacheable.
Closes#22264
* fixup! fix(@angular-devkit/build-angular): correctly extract messages when using cached build
Previously, when using an older version of the Angular CLI, during `ng update`, we download the temporary `latest` version to run the update. The ensured that when running that the runner used to run the update contains the latest bug fixes and improvements.
This however, can be problematic in some cases. Such as when there are API breaking changes, when running a relatively old schematic with the latest CLI can cause runtime issues, especially since those schematics were never meant to be executed on a CLI X major versions in the future.
With this change, we improve the logic to determine which version of the Angular CLI should be used to run the update.
Below is a summarization of this.
- When using the `--next` command line argument, the `@next` version of the CLI will be used to run the update.
- When updating an `@angular/` or `@nguniversal/` package, the target version will be used to run the update. Example: `ng update @angular/core@12`, the update will run on most recent patch version of `@angular/cli` of that major version `@12.2.6`.
- When updating an `@angular/` or `@nguniversal/` and no target version is specified. Example: `ng update @angular/core` the update will run on most latest version of the `@angular/cli`.
- When updating a third-party package, the most recent patch version of the installed `@angular/cli` will be used to run the update. Example if `13.0.0` is installed and `13.1.1` is available on NPM, the latter will be used.
When optimizations are enabled (either scripts or styles), an additional column will now be present in the output report shown in the console for an application build. This additonal column will display the estimated transfer size for each file as well as the total initial estimated transfer size for the initial files. The estimated transfer size is determined by calculating the compressed size of the file using brotli's default settings. In a development configuration (a configuration with optimizations disabled), the calculations are not performed to avoid any potential increase in rebuild speed due to the large size of unoptimized files.
Closes: #21394
When a builder-based command is executed (build, serve, test, etc.) and the builder's node package cannot be found a more user-friendly error message is now displayed. In addition, when the builder's node package cannot be found, a check is performed to determine if the node packages for the workspace may have not been installed. Previously, a potentially long stacktrace was shown which did not provide much information regarding how to correct the issue.
Closes: #10536
With #21986 we now error when updating `@angular/` and `@nguniversal/` packages across multiple major versions. With this chnage we update `ng update` output to show the correct instructions.
Before
```
$ ng update --next
We analyzed your package.json, there are some packages to update:
Name Version Command to update
--------------------------------------------------------------------------------
@angular/cli 12.2.12 -> 13.0.0-rc.2 ng update @angular/cli --next
@angular/core 11.2.14 -> 13.0.0-rc.2 ng update @angular/core --next
```
Now
```
$ ng update --next
We analyzed your package.json, there are some packages to update:
Name Version Command to update
--------------------------------------------------------------------------------
@angular/cli 12.2.12 -> 13.0.0-rc.2 ng update @angular/cli --next
@angular/core 11.2.14 -> 12.2.9 ng update @angular/core@12
```
Closes#19381
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"
}
}
...
}
```
With the removal of support for the string form of `loadChildren` within the Angular router, the usage of `System.import` has also been removal from `@angular/core`. This removal allows for the additional removal of all workarounds within the Angular CLI due to the `System.import` usage. Webpack's deprecated support for `System.import` was previously required to be enabled which resulted in warnings that then needed to be suppressed. A Webpack context dependency replacement was also previously required to prevent Webpack from failing due to the otherwise unknown behavior of the `System.import` call. All of these workarounds have now been removed.
The `material-design-icons` package has not been updated in 5 years and is a large package (40+MB) that frequently causes CI flakes. The recommended method to including the Material design icons is with the Google Fonts API via a index HTML link element (allows for font inlining during production builds). As a result, this test has now been removed.
Node.js v16's `fs.rmdir` will now throw an `ENOENT` error if the path does not exist. `fs.rm` is now the preferred option when using Node.js v16 but since this function is not available on Node.js v12 both are tried with `fs.rm` given preference.
Node.js v16 will be entering an LTS state prior to the release of Angular v13 which allows Node.js v16 to be marked as officially supported by the Angular CLI. The initial bootstrapping check now adds Node.js v16 to the output message in the event of an unsupported Node.js version.
NOTE: Prior to the final v13 release, the Node.js v16 minor should be updated to the actual LTS version once available.
rxjs 6 requires directory imports which are not support in ES modules. Disabling `fullySpecified` allows Webpack to ignore cases such as this until the package can be updated to use package exports.
One E2E test was still using the deprecated string-form of the routing `loadChildren` property. The `loadChildren` usage has now been converted to use the suppported dynamic import form. The string-form has been removed from Angular v13.
