The E2E schematic will now (as it did previously) skip adding dependencies
if they already exist within the `package.json` regardless of the specifier.
This is accomplished with the `existing` option for the `addDependency` rule
which allows defining the behavior for when a dependency already exists.
Currently the two option behaviors are skip and replace with replace being
the default to retain behavior for existing rule usages.
When using the `addDependency` helper rule, a package specifier mismatch will
now result in a warning instead of an error. This prevents the potential
for breaking changes in schematics that previously allowed the behavior.
The warning will also display the existing and new specifiers to better inform
the schematic user of the outcome of the schematic.
The `root` property is required in a workspace project. Now we issue an actionable warning message when this is missing.
Note: this will become an error in the next major version.
Closes: #21310
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.
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
With this change we update the validation of the libraries and application projects names to fully allow characters that make a valid NPM package name. http://json.schemastore.org/package has been used as reference.
We also remove validators that are no longer needed.
Closes#11051
`rxjs` 7 versions prior to 7.4.0 did not export the ES2015 variant in a way that could be leveraged via the new package.json `exports` feature. As a result, prior versions would cause larger ES5 variants of rxjs to be bundled within applications. Version 7.4.0 is now set as the minimum version for new projects to allow for the ES2015 rxjs code to be used when building applications.
With the Angular framework supporting rxjs 7 for Angular 13, new projects (`ng new ...`) can now be created using rxjs 7. rxjs 6 is also still fully supported with Angular 13 allowing existing projects to continue to use rxjs 6 if preferred or required.
Support for rxjs 7 within the framework was enabled via https://github.com/angular/angular/pull/42991
