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.
The number prompt type currently prevents correction of an invalid user entered value after schema validation. An input type is now used instead. Type coercion based on the schema type(s) already occurs during the filter phase for the inquirer question.
This change converts answers from prompts into the property type requested from the schema. This allows properties that expect a number to correctly validate when an input prompt is used.
With this change we use the addUndefinedDefaults transformer post validation and don't create prompts which have a default value when options.defaults is truthy.
Closes: #18692
With this change we fix two analytics collection bugs:
- We now collect the usage of options defined in the workspace config (angular.json).
- We now also collect values set via schematic prompts.
Closes: #17900
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.
The `@angular/cli` package contains a built-in version of the `@schematics/angular` package. The module resolution paths for the schematics workflow should not assume package hoisting behavior when resolving. This change corrects that oversight.
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
This PR provides a way for subclass that extends `SchematicCommand` to
provide a different default collection name.
This is needed in g3 where the collection name is different from
external.
Fix#14986
This PR includes some refactoring to simplify the interaction
of the `NodeWorkflow` and the `BaseWorkflow` with the registry.
We were registering redundant `addPostTransform`s. Some of them in
the constructor of the `BaseWorkflow`, which did not allow us to
intercept `addUndefinedDefaults`.
Additionally, we were setting the `validateOptionsWithSchema` transform
multiple times unnecessarily.
An issue left to fix is support for the `--project` option in
schematic commands. Currently, `getProjectName` does not know about
this option, since `createWorkflow` does not know how to parse the
command line arguments. The parsing logic is implemented partially
by the concrete implementation of the `SchematicCommand` template
method.
Some commands (like schematics) need to have custom reporting for
analytics. Schematics and Architect commands need to verify if the
schematic/architect builder run is in the safelist, for example.
* feat(@angular/cli): Added support for multiselect list prompt
* If multiselect option is true use the checkbox
inquirer prompt type, otherwise use list.
* feat(@angular-devkit/core): Added support for multiselect list prompt
* Added multiselect to PromptDefinition interface and usages
The feature comes from the "x-deprecated" field in schemas (any schema that is used
to parse arguments), and can be a boolean or a string.
The parser now takes a logger and will warn users when encountering a deprecated
option. These options will also appear in JSON help.
SubCommands are not tied to the option that triggers them. They
contain a subset of a CommandDescription interface, with at least
a short and long description and usage notes. These are generated
from the subcommand schema (e.g. schematics in case of generate).
