BREAKING CHANGE:
With this change we remove the following deprecated APIs
- `TslintFixTask`
- `TslintFixTaskOptions`
**Note:** this only effects schematics developers.
This change allows consumers of the `NodeWorkflow` to configure the package installation task to use a package manager's `--force` option. This will be used by the `@angular/cli` update command when the update command's force option is used. This change is not intended to enable a schematic to adjust the force option.
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.
This change allows option transforms to be directly provided to the NodeWorkflow instead of needing to access the engine host inside the workflow after creation. This also allows option transforms to affect the options prior to schema validation (if enabled).
This change provides an additional NodeWorkflow option `schemaValidation`. When enabled, this new option will setup schema-based validation of a schematics options prior to schematic execution. The schema registry provided with the NodeWorkflow is used to perform the validation. This new option removes the need to manually configure validation of schematic options when initializing a schematic runtime.
This change allows the creation of a NodeWorkflow class with a path string instead of requiring a fully configured filesystem host object. This reduces the amount of code necessary to setup a schematics runtime for common cases.
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.
Schematics context now have an (optional) analytics field that, if set,
should be used to report usage. This can be set even in some cases where
analytics is disabled (to a noop analytics).
And receives in its constructor the enginehost and registry. This simplifies the creation
of the NodeWorkflow, or later on the Google3Workflow etc, since all the duplicate logic
is now in a single base class.
This is yak shaving for internal stuff.
