Running autocompletion with `14.0.1` installed globally in a `14.0.0` project logs the version warning in a very annoying fashion:
```
$ ng verYour global Angular CLI version (14.0.1) is greater than your local version (14.0.0). The local Angular CLI version is used.
To disable this warning use "ng config -g cli.warnings.versionMismatch false".
sion
```
This adds an exception for `ng completion` commands to avoid this edge case.
Currently, we don't register all available commands. For instance, when the CLI is ran inside a workspace the `new` command is not registered. Thus, this will cause a confusing error message when `ng new` is ran inside a workspace.
Example:
```
$ ng new
Error: Unknown command. Did you mean e?
```
With this commit we change this by registering all the commands and valid the command scope during the command building phase which is only triggered once the command is invoked but prior to the execution phase.
Prepares the `@angular/cli` package for the eventual change of enabling the
TypeScript `useUnknownInCatchVariables` option. This option provides additional
code safety by ensuring that the catch clause variable is the proper type before
attempting to access its properties. Similar changes will be needed in the other
packages in the repository prior to enabling `useUnknownInCatchVariables`.
When the workspace has multiple projects and we the project to use cannot be determined from the current working directory, we now issue an actionable error message.
Angular CLI versions prior to v14 may not exit correctly if not forcibly exited
via `process.exit`. When the local CLI version is less than v14, the CLI will now
use `process.exit` to ensure the process exits with these older CLI versions.
Fixes#23289
In certain situations the existing console logger created via `@angular-devkit/core` `createConsoleLogger`
could try to write to a closed stdout pipe stream. This would result in an error during
execution. For cases such as the completion script command, this would also prevent the
command from functioning. To mitigate these cases, `createConsoleLogger` is no longer used
and instead a logger instance is directly created within the CLI that uses `Console.log`
and `Console.error` to write output. Exiting the CLI also now waits for messages to be
logged before proceeding with the exit.
Previously, when a global configuration was not found on disk we forcefully created it even when it was not needed.
This causes issues in CI when multiple `ng` commands would run in parallel as it caused a read/write race conditions.
See: https://angular-team.slack.com/archives/C46U16D4Z/p1654089933910829
With this change we add a footer to indicate that more commands are available when running the CLI in a different context. Ie inside or outside of a workspace.
The package manager `--force` option is only relevant to npm 7+ wherein the option controls
the strictness of the npm 7+ peer dependency resolution. Yarn 2+ does not support a `--force`
option. When the `ng update` `--force` option was used, `ng update` was incorrectly
applying the package manager `--force` option to Yarn which lead to an installation failure.
This has now been corrected and the package manager `--force` option is now only applied to npm 7+.
Yarn 2 and higher no longer support the `--silent` flag.
The Angular CLI will now spawn package managers with the stdout ignored when silent
mode is needed and only show stderr when the process exits unsuccessfully. This
provides the necessary functionality for the CLI without relying on package manager
options.
npm 7+ can fail due to it incorrectly resolving peer dependencies that have valid SemVer
ranges during an `ng update`. Update will set correct versions of dependencies within the
package.json file. However, the failing npm package installation will cause the update process
to abort. To workaround these errors, the npm force option is set during package
installation when the npm package manager at version 7.0.0 or greater is used during an update.
Example error:
```
npm ERR! Conflicting peer dependency: @angular/compiler-cli@14.0.0-rc.0
npm ERR! node_modules/@angular/compiler-cli
npm ERR! peer @angular/compiler-cli@"^14.0.0 || ^14.0.0-rc" from @angular-devkit/build-angular@14.0.0-rc.0
npm ERR! node_modules/@angular-devkit/build-angular
npm ERR! dev @angular-devkit/build-angular@"~14.0.0-rc.0" from the root project
```
With this change we change the how we handle `"format": "path"` schematic property option. We replace the formatter in favour of a `SmartDefaultProvider`, which ensures that nested schematics can access the `workingDirectory`.
If the user does not have a global install of the Angular CLI, the autocompletion prompt is skipped and `ng completion` emits a warning. The reasoning for this is that `source <(ng completion script)` won't work without `ng` on the `$PATH`, which is only really viable with a global install. Local executions like `git clone ... && npm install && npm start` or ephemeral executions like `npx @angular/cli` don't benefit from autocompletion and unnecessarily impede users.
A global install of the Angular CLI is detected by running `which -a ng`, which appears to be a cross-platform means of listing all `ng` commands on the `$PATH`. We then look over all binaries in the list and exclude anything which is a directo child of a `node_modules/.bin/` directory. These include local executions and `npx`, so the only remaining locations should be global installs (`/usr/bin/ng`, NVM, etc.).
The tests are a little awkward since `ng` is installed globally by helper functions before tests start. These tests uninstall the global CLI and install a local, project-specific version to verify behavior, before restoring the global version. Hypothetically this could be emulated by manipulating the `$PATH` variable, but `which` needs to be available (so we can't clobber the whole `$PATH`) and `node` exists in the same directory as the global `ng` command (so we can't remove that directory anyways). There's also no good way of testing the case where `which` fails to run.
Closes#23135.
This explains how to set up autocompletion with the Angular CLI:
1. Via the automated prompt on first execution.
2. Via `ng completion`.
3. Manually via appending `source <(ng completion script)` to the user's `~/.bashrc` file.
It also specifically calls out supported and unsupported platforms as well as the requirement for a global install of the Angular CLI.
For v14, the update command migration execution logic was incorrectly exiting after
the success of the first package's migrations. This prevented any other updated
packages from executing migrations automatically. The success check is now a failure
check and will allow the migration execution process to continue to execute migrations
until complete or a failure occurs.
When the `--search` option is passed to `ng doc`, it should open a URL
that does a search across the whole website (instead of the default
behavior of limiting the search to API docs).
Fix the `ng doc` command to implement the iteded behavior (previously,
it did the opposite).
Relative schematics referenced in `angular.json` `schematicCollections` and `defaultCollection` were always resolved from the current working directory, which is not correct and caused the collection not to be resolved when the this is different from the location of the workspace config.
Closes#23136
Windows Cmd and Powershell don't support autocompletion, but it can be done with utilities like Windows Subsystem for Linux and Git Bash, which should "just work" due to emulating a Linux environment. This clarifies the error message most users will see to call out the state of the world with regard to autocompletion on Windows platforms.
`ng update` is most likely called when upgrading a project to the next version and users should be more concerned about their project than their personal terminal setup.
`ng completion` is unconditionally setting up autocompletion, while `ng completion script` is getting the shell script for autocompletion setup. As a result, both of these don't benefit from a prompt and should be safe to skip it.
After the user rejects the autocompletion prompt or accepts and is successfully configured, the state is saved into the Angular CLI's global configuration. Before displaying the autocompletion prompt, this state is checked and the prompt is skipped if it was already shown. If the user accepts the prompt but the setup process fails, then the CLI will prompt again on the next execution, this gives users an opportunity to fix whatever issue they are encountering and try again.
Refs #23003.
When the CLI is executed with any command, it will check if `ng completion script` is already included in the user's `~/.bashrc` file (or similar) and if not, ask the user if they would like it to be configured for them. The CLI checks any existing `~/.bashrc`, `~/.zshrc`, `~/.bash_profile`, `~/.zsh_profile`, and `~/.profile` files for `ng completion script`, and if that string is found for the current shell's configuration files, this prompt is skipped. If the user refuses the prompt, no action is taken and the CLI continues on the command the user originally requested.
Refs #23003.
`ng completion` is changed to set up Angular CLI autocompletion for the current user by appending `source <(ng completion script)` to their `~/.bashrc`, `~/.bash_profile`, `~/.zshrc`, `~/.zsh_profile`, or `~/.profile`.
The previous `ng completion` functionality (printing Yargs autocompletion shell script) is moved to `ng completion script` because most users won't need to worry about this, so we're prioritizing `ng completion` as the part most users will actually type.
I couldn't find a good way of testing an error when writing to the `~/.bashrc` file. Since the CLI checks if it has access to the file first, that would usually fail in any circumstance when the file can't be written to. Things could change in between (user modifies file permissions or disk runs out of storage), but there's no easy hook to simulate this change in the e2e test.
Refs #23003.
To enable bash and zsh real-time type-ahead autocompletion, copy and paste the generated script by the `ng completion` command to your `.bashrc`, `.bash_profile`, `.zshrc` or `.zsh_profile`.
Closes#11043
This changes removes most of the usage of `getWorkspaceRaw` in the Angular CLI. This is needed to eventually drop the direct dependency on `jsonc-parser`.
