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.
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
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.
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.
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.
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.
With this change we automate the generation of `@angular/cli/lib/config/schema.json`. While on paper we could use quicktype for this. Quicktype doesn't handle `patternProperties` and `oneOf` that well.
How does this works?
Relative `$ref` will be resolved and inlined as part of the root schema definitions.
Example
```json
"@schematics/angular:enum": {
"$ref": "../../../../schematics/angular/enum/schema.json"
},
```
Will be parsed and transformed to
```json
"@schematics/angular:enum": {
"$ref": "#/definitions/SchematicsAngularEnumSchema"
},
"definitions: {
"SchematicsAngularEnumSchema": {
"title": "Angular Enum Options Schema",
"type": "object",
"description": "Generates a new, generic enum definition for the given or default project.",
"properties": {...}
}
}
```
Some schematic only packages may not have entry points defined (`main`/`exports`). These type of packages will now be correctly resolved when attempting to locate update migrations.
Fixes#20032
Failure to resolve a migration package from the workspace root will now not crash and instead error with a message. Verbose logging (`--verbose`) is also added to provide more details regarding the resolution process.
This change will display an error message if using npm 7 (or versions earlier than 6). This is a temporarily change while npm 7 usability concerns are addressed.
This change ensures that migration collections defined in a package's `ng-update` metadata are resolved from the containing package. This avoids issues that may arise from package manager hoisting behavior which can result in the wrong migration collection being chosen. The `--migrate-only` option already contained this resolution logic and now the full update contains it as well.
This change adds logic to redirect module resolution requests for Angular schematics to ensure that the correct versions of core schematic related packages are used. This also ensures that the runtime version of the schematics package matches the version used inside the schematic and that object instances passed into the schematic are compatible.
The current set of core schematic related packages are `@angular-devkit/*` and `@schematics/angular`. Only first-party Angular schematics are currently affected by this change.
For `ng update --migrateOnly ...` the update implementation checks for transitive
dependencies and tries to parse the containing directory as JSON. This PR
fixes this by providing the correct path to the package.json.
This change reduces the amount of schematic runtime setup code by leveraging the new options for the root path and schema validation in the NodeWorkflow class.
Previously, the workspace configuration file was found and loaded by individual commands potentially multiple times. This change moves the initial workspace location discovery and loading of the workspace to the CLI startup. It also provides the workspace to each command so that the commands can reuse the already loaded and parsed workspace configuration.
'--all' functionality has been removed from `ng update` as updating multiple packages at once is not recommended. To update the depencencies in your workspace 'package.json' use the update command of your package manager.
Closes#15278Closes#13095Closes#12261Closes#12243Closes#18813
These addresses;
- When a large number of migration are executed, it's hard to differentiate between the title and description.
- Fix alignments of logs
When an error occurs during ng update we currently discard the stack trace which in some cases made it hard to identify the cause of the error.
Now, we print the stack trace to a log file similarly to unhandled exceptions.
Example of CMD output;
```cmd
** Executing migrations of package '@angular/core' **
> Static flag migration.
Removes the `static` flag from dynamic queries.
As of Angular 9, the "static" flag defaults to false and is no longer required for your view and content queries.
Read more about this here: https://v9.angular.io/guide/migration-dynamic-flag
× Migration failed: x
See "C:\Users\alag\AppData\Local\Temp\ng-NgmC1G\angular-errors.log" for further details.
```
Example of log file contents:
```txt
[error] Error: x
at UpdateCommand.executeSchematic (C:\git\angular-cli\test\node_modules\@angular\cli\commands\update-impl.js:98:19)
at UpdateCommand.executePackageMigrations (C:\git\angular-cli\test\node_modules\@angular\cli\commands\update-impl.js:167:39)
at UpdateCommand.executeMigrations (C:\git\angular-cli\test\node_modules\@angular\cli\commands\update-impl.js:161:21)
at UpdateCommand.run (C:\git\angular-cli\test\node_modules\@angular\cli\commands\update-impl.js:394:38)
at async UpdateCommand.validateAndRun (C:\git\angular-cli\test\node_modules\@angular\cli\models\command.js:134:28)
at async Object.runCommand (C:\git\angular-cli\test\node_modules\@angular\cli\models\command-runner.js:201:24)
at async default_1 (C:\git\angular-cli\test\node_modules\@angular\cli\lib\cli\index.js:62:31)
```
This allows the CLI version check during update bootstrapping to be disabled via the `NG_DISABLE_VERSION_CHECK` environment variable. This is not considered an officially supported option and is intended mainly for testing/troubleshooting scenarios.
This is a workaround for the schematics runtime to support the requirement of packages containing migrations (or other schematics) to not have a direct/runtime dependency on the schematics package.
Closes: #16392
We don't actually know for certain that the migration was successful, only that it finished. This updates the messaging to be more clear about this distinction. I also removed the check mark and green coloring which implied success.
Fixes#16060.
Any time a `git commit` is made, the CLI now prints out the hash and short message. For migrations, the message is simply the first line of the commit. For schematics, the commit message isn't all that helpful, so I used the list of packages instead.
