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.
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
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
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.
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.
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.
`tsickle` doesn't be a dependency in users projects, if it is most certain it will cause updates to fail due to mismatching peer dependency on TypeScript.
Deprecated packages that may have been included in a project by the tooling are now ignored when validating an update. This change removes the need to use the `--force` option in a situation where the later migrations will remove and cleanup the deprecated packages.
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.
