Files should not redirect `@angular/core` and instead use the direct dependency of the `@schematics/angular` package. This allows old major version migrations to continue to function even though the latest major version may have breaking changes in `@angular/core`.
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
Certain older versions of packages may contain missing or invalid peer dependencies. As a result these packages may be incorrectly added to the project when no newer compatible version is found. An exclusion list is now present within `ng add` that will exclude packages with known peer dependency concerns from consideration when adding a package. Currently, only `@angular/localize@9.x` is included in the list.
With this change we fix an issue were migrations are not run when the version specified in migration collection is specified as stable example `13.0.0`, but the version specified in the `package.json` is still a prerelease example `13.0.0-rc.0`.
Closes: #21969
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"
}
}
...
}
```
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.
In the case of the update command, the usage was guarded by a try/catch block with the downside of leaving the `fs.rmdir` being that a deprecation warning would be shown when running the command which is not ideal.
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.
The original update analysis would prepend the package name to all migration collection files. This was required at the time to ensure the migration collection files would be found. The existing update logic, however, no longer requires this change but the change previously had no negative effects as both the relative and module specifier methods would successfully resolve the migrations. But with the conversion to ESM-based packages that use the package.json `exports` field, deep imports into a package are no longer possible unless the migration collection files are explicitly exported. Relative migration collection paths are now preferred since they are based off of the location of the package's `package.json` and do not require additional `exports` field entries. The original update analysis logic, unfortunately, prevent the relative paths from working as intended. Since this original logic is no longer required by the update process, it has been removed allowing the relative paths to be kept and used directly.
To support the eventual migration of the CLI to ESM, the CLI commandline tool is now bootstrapped by dynamically importing the main initialization code. This is done to allow the main bin file (`ng`) to remain CommonJS so that older versions of Node.js can be checked and validated prior to the execution of the CLI. This separate bootstrap file is needed to allow the use of a dynamic import expression without crashing older versions of Node.js that do not support dynamic import expressions and would otherwise throw a syntax error. This bootstrap file is required from the main bin file only after the Node.js version is determined to be in the supported range. The use of the dynamic import expression allows CommonJS code to execute either CommonJS or ESM code.
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.
Much like the framework packages, the VERSION property will eventually be set via build-time stamping but the necessary build infrastructure is not yet in place. Until then, the global require usage has been replaced with a file read and JSON parse which provides the equivalent required behavior.
To support the eventual conversion of the `@angular/cli` package to ESM, the usage of the global require function must be removed as it is not supported in ESM code. Node.js does have the facility to create custom require functions that can be used when the need to synchronously load a file at runtime is required. Such cases have now been converted to use custom require functions where appropriate.
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.
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 typings package was already present for `npm-package-arg` and the removal of require usage supports the eventual shift to an ESM output for the CLI package.
Some organizations are moving away from storing tokens/secrets in an NPM config file in favor
of environment variables that only exist for the span of a terminal session. This commit will
make sure those variables are read even when there is no NPM config file present.
