In some cases, when a migration fails an error is not thrown, instead the `executeMigration` return a `false` value when resolved.
With this change, we fix an issue were failed migrations resulted in the process of not terminating with a non-zero error code.
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.
To improve the developer experience for the `ng lint` command in new projects, the lint command will now ask the developer if they wish to install `@angular-eslint/schematics` when no lint target has been configured for the specified project. `@angular-eslint/schematics` is currently the only option listed in the warning shown prior to the introduction of the prompt in this change. If additional example packages are added to the warning text in the future, the confirmation prompt should be changed to a list prompt which would allow the user to pick one of the potential future listed example packages.
Closes: #21387
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.
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.
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.
The CLI contains a helper class instance that provides the version of the executing CLI. By using this helper throughtout the code, repeat `require` calls are no longer necessary.
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
Unsupported versions of Node.js will now show an unsupported warning when the `ng version` command is executed.
Currently Node.js major versions 12 and 14 are considered supported and tested.
Closes#20879
Prior to performing the initial updated package installation during the `ng update` process, the workspace node modules directory will be removed. This cleaning increases the guarantees that the package manager will hoist packages into the correct locations and avoid peer dependency inconsistencies.
With this change we allow unset a config value to be a JSON.
Example, `ng config -g schematics {}` will remove the entire `schematics` section from the configuration.
With this change we allow unset a config value when the provided value is `undefined`.
Example, `ng config -g schematics undefined` will remove the entire `schematics` section from the configuration.
When the CLI update command's `--force` option is used, the underlying package manager will also be executed with its force option. This behavior is especially important with the advent of npm 7 which will fail installation if any peer dependency version ranges are mismatched.
With this change we change the package installation to async. This is needed as otherwise during `ng-add` the spinner gets stuck. With this change we also add the spinner in the installation methods.
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.
With this change we consider the update schematics are idempotent. When updating from or between prereleases we will execute all migrations for the version.
This change removes the need for the `@schematics/update` package within the Angular tooling and removes the dependency from the `@angular/cli` package.
Only the `update` schematic from the `@schematics/update` package was used and this schematic's logic will eventually be folded into the update command logic directly.
