The standalone component helper utilities introduced into the `@angular/cdk` via
https://github.com/angular/components/pull/24931 have been added to an export path (`private/components`)
within `@schematics/angular`. The export path is primarily intended for the use of the components schematics
within `@angular/cdk` and `@angular/material`. The API exported from this path is not considered public API,
does not provide SemVer guarantees, and may be modified or removed without a deprecation cycle.
When using the `addDependency` rule from `@schematics/angular/utility` a new option is now
available that supports controlling the rule's behavior when scheduling the `NodePackageInstallTask`.
Previously, the behavior was automatic and the rule would only schedule the task if it was not already
scheduled by a previous `addDependency` rule usage for the `package.json`. This behavior is still the
default behavior. However, it can now be customized per rule invocation via the `install` rule option
which can be either `InstallBehavior.None`, `InstallBehavior.Auto`, or `InstallBehavior.Always`.
Updates the E2E schematic to use the workspace and dependency utility rules exported from `@schematics/angular/utility`.
This change also removes the use of the custom path manipulation functions from `@angular-devkit/core`.
The development dependency versions for `protractor` and `jasmine-spec-reporter` are also moved to the latest
versions helper `package.json` file. This move allows the versions to be automatically updated via renovate
instead of hardcoded in the schematic source code.
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`.
With the APF changes in version 14, the dts entrypoint file has been changed to `index.d.ts`, this results in TypeScript being able to resolve the type definition file without the need of the additional path to the flat module file dts.
`package.json` files have been remove from secondary entrypoints in version 14 of Angular package format (APF).
With this change we delete the now redundant files and in case these contained the deprecated way of how to configure secondary entrypoints in ng-packagr we migrate these as well.
The `@schematics/angular` package now contains a defined set of package `exports` including a `utility` subpath export.
A wildcard export is also temporarily defined to support transition away from existing deep-import usage.
The `@schematics/angular/utility` subpath export will contain supported utility methods used by the first-party schematics
contained within the `@schematics/angular` package and can be considered public API that will follow SemVer stability constraints.
The first group of utilities introduced in this change are used to modify the `angular.json` workspace file
within the schematics and include the `updateWorkspace` rule and `readWorkspace`/`writeWorkspace` helpers.
An `addDependency` schematics rule has been added to the newly introduced `utility` subpath export for the `@schematics/angular` package.
This new rule allows for adding a package as a dependency to a `package.json`. By default the `package.json` located
at the schematic's root will be used. The `packageJsonPath` option can be used to explicitly specify
a `package.json` in a different location. The type of the dependency can also be specified instead
of the default of the `dependencies` section by using the `type` option for either development or peer dependencies.
Code related to decoding buffers into strings and parsing content into JSON can now be removed by using the
support provided directly from the Tree instance for the executing schematic.
Several imported types and values from `@angular-devkit/core` could be removed while still
maintaining the same functionality. This further reduces the schematics direct dependence
on the `@angular-devkit/core` package.
By using the `strings` re-export from `@angular-devkit/schematics` instead of from `@angular-devkit/core`,
the number of imports from `@angular-devkit/core` has been reduced and lowers the direct dependency count
for many of the individual schematics.
Due to incorrect castings previously the code would crash when the module doesn't contain an routing module with the following error:
```
Cannot read property 'properties' of undefined
```
Closes#21397
The `schematicCollections` can be placed under the `cli` option in the global `.angular.json` configuration, at the root or at project level in `angular.json` .
```jsonc
{
"$schema": "./node_modules/@angular/cli/lib/config/schema.json",
"version": 1,
"cli": {
"schematicCollections": ["@schematics/angular", "@angular/material"]
}
// ...
}
```
**Rationale**
When this option is not configured and a user would like to run a schematic which is not part of `@schematics/angular`,
the collection name needs to be provided to `ng generate` command in the form of `[collection-name:schematic-name]`. This make the `ng generate` command too verbose for repeated usages.
This is where `schematicCollections` comes handle. When adding `@angular/material` to the list of `schematicCollections`, the generate command will try to locate the schematic in the specified collections.
```
ng generate navigation
```
is equivalent to:
```
ng generate @angular/material:navigation
```
**Conflicting schematic names**
When multiple collections have a schematic with the same name. Both `ng generate` and `ng new` will run the first schematic matched based on the ordering (as specified) of `schematicCollections`.
DEPRECATED:
The `defaultCollection` workspace option has been deprecated in favor of `schematicCollections`.
Before
```json
"defaultCollection": "@angular/material"
```
After
```json
"schematicCollections": ["@angular/material"]
```
Closes#12157
.substr() is deprecated so we replace it with .slice() which works similarily but isn't deprecated
Signed-off-by: Tobias Speicher <rootcommander@gmail.com>
With this change we refactor the Angular CLI and replace the underlying args parser and command builder. We choose to use Yargs as our parser and command builder of choice. The main advantages of Yargs over other command builders are;
- Highly configurable.
- We already use it in other packages such as the compiler-cli/dev-infra etc..
- Commands and options can be added during runtime. This is a requirement that is needed to support architect and schematics commands.
- Outstanding documentation.
- The possibility to parse args without parser configuration (Free form).
- Commands are built lazily based on the arguments passed.
BREAKING CHANGE:
Several changes in the Angular CLI commands and arguments handling.
- `ng help` has been removed in favour of the `—-help` option.
- `ng —-version` has been removed in favour of `ng version` and `ng v`.
- Deprecated camel cased arguments are no longer supported. Ex. using `—-sourceMap` instead of `—-source-map` will result in an error.
- `ng update`, `—-migrate-only` option no longer accepts a string of migration name, instead use `—-migrate-only -—name <migration-name>`.
- `—-help json` help has been removed.
Closes#20976, closes#16614 and closes#16241
BREAKING CHANGE:
The deprecated `showCircularDependencies` browser and server builder option has been removed. The recommended method to detect circular dependencies in project code is to use either a lint rule or other external tools.
With this change we update the TypeScript compilation target to `ES2020` for both new and existing projects. This is because all browsers that Angular supports (https://angular.io/guide/browser-support) support `ES2020` features without the need for polyfills.
