Updates to the TypeScript 4.8 RC and adds some code to account for a breaking change where the decorators and modifiers of an AST node have been combined into a single array.
`.` is not a valid character in ES6 class names.
Prior to this change `foo.module` before used to be incorrectly classified to `Foo.Module` instead of `FooModule`.
Closes#13824
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
Prior to this commit, we defined routes in two places example:
```ts
@NgModule({
declarations: [
HomeComponent
],
imports: [
CommonModule,
RouterModule.forChild(routes),
HomeRoutingModule
]
})
export class HomeModule { }
```
Closes#17139
With this change we remove the usage of hard coded `src` directory and instead infer this from the `sourceRoot` project option.
We also remove the `angularCompilerOptions.entryModule` property in the server tsconfig as this is no longer needed with Ivy.
Closes#12104
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
