Support schematics collection extending another one at root-level (like nx/nrwl)

[wSedlacek]

It would be great if this would support @nrwl/angular schematics as preferred default over @schematics/angular if it is installed.

[cyrilletuzi]

It's already the case: "Angular: Generate another schematics" command in a NX workspace will have @nrwl/angular selected by default.

As a more general answer, the extension will default to the collection set in angular.json:

{
  "cli": {
    "defaultCollection": "@nrwl/angular"
}

[wSedlacek]

@nrwl/angular extends @schematics/angular so it should supersede it.
This matters because by default in an Nx Workspace default settings are configured for @nrwl/angular

    "@nrwl/angular:component": {
      "style": "scss"
    }

In fact extended schematics do not even show up when selecting Angular: Generate another schematic which imho they should (Or at least have the option to)

In a newly created Nx Workspace using the Angular preset @schematics/angular is not even a direct dependency so when using pnpm it will not be located at node_modules/@schematics/angular unless you shamefully flatten or add it as a dependency. (This is fine so long as @nrwl/angular is used in it's place when ever it is installed)

One other thing that would be nice to fix is supporting workspace.json as an alternative to angular.json for projects that prefer using that.
It would also be nice if the install prompt for @schematics/angular used the cli.packageManager preference.

[cyrilletuzi]

Please open other "Ideas" discussions for the other topics you mention (pnpm, other config files, etc.), otherwise this one will quickly become a mess.

@nrwl/angular extends @schematics/angular

I was not aware it's possible to extend this way. The schematics API is (nearly) undocumented, and until Nx, the only schematics (I'm aware of) extending Angular ones were Ionic's one, and it does so in a different way (it redefines each command but specify it extends the Angular one).

So extends at root-level in collections should be supported in order to solve the problem. This is not a trivial thing to implement properly and it will require some time.

[wSedlacek]

I will open up new discussions for the other feature request.

As far as the path forward, would you like me to investigate how to implement support for extends at the root level or would you like to look into it further?

[cyrilletuzi]

As far as the path forward, would you like me to investigate how to implement support for extends at the root level or would you like to look into it further?

It depends on your other requests. For example, if you want proper pnpm support (to discuss in another thread), your help may be more useful, as I'm not used to pnpm at all, while it may be easier for me to look into the extend feature as I've done the initial implementation.

Technical description

It seems schematics collection can extend another one in 2 ways:

1. By redefining the schematic but extending it from another collection, example from @ionic/angular-toolkit:

{
  "schematics": {
    "class": {
      "extends": "@schematics/angular:class"
    }
  }
}

2. By extending a whole other collection, example from @nrwl/angular:

{
  "extends": ["@schematics/angular", "@nrwl/workspace"],
  "schematics": {}
}

Currently the extension supports only the first case.

Technical solution

1. Support the second type of extends on collection load (will happen in this file)

2. On shortcuts (ie. "Generate a component/service/module"), use the default collection set in angular.json if (and only if) it contains the related schematics (component, service, module schematics)

Details to discuss

• In the "Angular: Generate another schematic" scenario, given that the extended schematics are taken as is, with no modifications, adding them to the list of the final collection is of little interest compared to using the original schematic directly (the fact that shortcuts should behave differently is a separate issue). But it surely adds noise. So maybe we should sort the specific schematics first, and only then the extended ones.

• About the point 2 of the technical solution, I'm not sure if it should be managed for any collection or only for @nrwl/angular for multiple reasons:

  • we are not sure other tools would attach the default options values in angular.json to their collection or to @schematics/angular, so maybe it would need a more complex logic which would check that,

  • the extension documentation is currently discouraging the use of @ionic/angular-toolkit because it extends some schematics in a less powerful way than the original schematics and even sometimes with some issues, so it's better to use the official Angular schematics in this case; so here again it may need a more advanced logic: using another collection in shortcuts commands should be done only if the other collection is taking the original schematic as is, and not in the case it is replacing it with another behavior. In fact it is even a requirement, because the extension shortcuts expect the official Angular options, that may be missing in modified extended schematics.

[wSedlacek]

It depends on your other requests. For example, if you want proper pnpm support (to discuss in another thread)

See - #454

But it surely adds noise. So maybe we should sort the specific schematics first, and only then the extended ones.

I think this is fair, but even if they are at the end of the list I firmly think they should be included. I would feel differently if all the schematics were flattened to a single list but because you must first select a collection before selecting a schematic I believe the duplication concern isn't as relevant.

About the point 2 of the technical solution, I'm not sure if it should be managed for any collection or only for @nrwl/angular for multiple reasons:

It would also be nice to be able to use custom collections or even libraries intended for this purpose. I myself have been planning on authoring some schematics that follow my linting rules and preferences.
Perhaps there should be a setting for this extension to allow the user to choose to override the default schematics similar to how ngschematics.schematics allows you to add additional schematics?

[kvart714]

Hello @cyrilletuzi
I have been using your extension for over a year.
Right-click -> Angular: Generate a component saves a lot of time!

But lately, the standard behavior of ng g c no longer satisfies me.

So I created my schematic in the project, I called it "component" and added it to the defaultCollection.
Inside, I call the standard externalSchematic('@schematics/angular', 'component', options) and then make the changes I need.

Now ng g c works perfect for me. But I sadly discovered that Angular: Generate a component still uses the default @schematics/angular.

It seems to me that if

1. there are other schematics in the project
2. it is set to defaultCollection
3. it is intentionally named "component" and has same scheme

then there is no reason why you would need @schematics/angular as a daily action.

[cyrilletuzi]

Hi,

This is the intended behavior, and your technical description mentions why:

has same scheme

That is not possible to check. The "Generate a component" command is a shortcut command and relies on several options and behaviors from the official Angular CLI. The extension can't be sure another schematic respect these options and behaviors. It could even lead to issues, which already happened (with @ionic/angular-toolkit).

For information, I released an enhanced version of this extension, Schematics Pro, where you could:

• create your own schematics with a much simpler syntax than with Angular CLI APIs
• disable the default schematics if you want
• associate schematics to paths so you don't even have to choose the schematic
• get other unrelated features like schematics for other frameworks (React, Vue, Nest,...)