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.
At the moment there is no way to turn on the verbose logging for `ng update` and `ng add`. This is useful for use so that when users report issues such as npmrc is not read we can see the lookup locations.
This also removes some reduncant that were being provided in `executeSchematic`.
Related to https://github.com/angular/angular-cli/issues/14993
The lazy option inside the script and style option is confusing as this option doesn't lazy load a bundle but rather it doesn't inject/reference the script in the HTML. While this option is an enabler for lazy loading, the users will still need to handle on how how this bundle will be lazy loaded. There are also potential use cases beyond lazy loading for the option.
Closes#14814
Follow-up to #14788 that allowed `ng doc --version 6`.
This commit enhances the doc command to use the current Angular version of the project by default, if no version is provided explicitely.
Fixes#12365
On prompt only, does not contain any user info. Since prompt should be only
shown at install or first run, this is not going to ping more than once and
the users privacy is also protected.
As the JSON Schema validation is minimum in the CLI, we have to also validate in code.
This PR:
- updates the JSON Schema to use `number` and `enum` instead of `integer` and `const` that are not supported.
- adds validation in the doc command implementation
- adds error reporting if the version is not valid
- fixes a typo in an error message in the parser
When testing a local CLI build with `npm link @angular/cli`, if you run `ng version`,
you currently see:
Angular CLI: local (v8.1.0-beta.2+24.3bb67d8.with-local-changes, branch: version)
if the Git branch is `fix/version`.
Whit this PR, `ng version` now displays the proper Git branch name:
Angular CLI: local (v8.1.0-beta.2+24.3bb67d8.with-local-changes, branch: fix/version)
Whenever an unhandled exception during command processing occurs, the message and stack trace will be saved to a debug log located in a temporary directory. The user will be informed of the log location as well as the exception message and instructions to file a bug report at the GitHub repository.
Node.js 10+ provides built-in functionality to test for color support based on chalk's `supports-color` package as well as several others. This alleviates the need for custom code or third-party packages to determine color support. In addition for this PR, the `ansi-colors` package is added to the CLI which provides color, cross-platform symbol, and style/color removal support. The package is light-weight, contains typings, and has no dependencies. The removal support is leveraged to remove all styling from logger messages when color is not supported. This removes a current defect in which color/styling is still displayed if generated manually or via methods that do not perform supportability checks. Finally, the typically used console functions are overriden to leverage the logger to ensure that the color processing is applied to third-party code (e.g., webpack internally as well as some of its loaders and plugins) which output to the console directly.
With this commit, we can now specify a `version`
for the `ng doc` command
ng doc --version 6
ng doc -v 6
and this will open `v6.angular.io` instead of `angular.io`.
The default domain is still used
if no version is specified.
Refs #12365
This ensures that migration fields that reference other packages use the package version specified in the migrating package's dependencies and not the version that a package manager happens to hoist to the root of the workspace.
