BREAKING CHANGE:
Deprecated option `--prod` has been removed from all builders. `--configuration production`/`-c production` should be used instead if the default configuration of the builder is not configured to `production`.
BREAKING CHANGE:
`--all` option from `ng update` has been removed without replacement. To update packages which don’t provide `ng update` capabilities in your workspace `package.json` use `npm update`, `yarn upgrade-interactive` or `yarn upgrade` instead.
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
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 this change we favor the `packageGroupName` name when specified and only fallback to use the first item in in the `packageGroup` array when it is not specified.
Closes#22087
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.
