feat(@angular/cli): specify multiple default collections

[tomastrajan]

Hi 😉

This PR is related to issue posted on angular/devkit repository by @jeffbcross . It looks like the whole implementation of executing schematics belongs to @angular/cli itself so that's the reason for creating PR against this repo.

The proposed solution adds possibility to specify additional collections property in defaults of schematics in angular-cli.json. That way app has base collection which defaults to @schematics/angular (but could be overridden too) and potential to add unlimited additional collections. Execution priority is that the first collection containing requested schematics wins.
the additional collections property should make this solution backwards compatible.

This is initial working implementation. Review of someone who knows that part would be highly appreciated. Also some guidance on how to test this is very welcome.

Check out screenshot of working solutions.

[tomastrajan]

No need to retrieve config value from multiple places. Now it's always responsibility of the caller.

[tomastrajan]

No need to retrieve config value from multiple places. Now it's always responsibility of the caller.

[tomastrajan]

List schematics per collection

[tomastrajan]

@clydin a bit meta question, how does it work with this repo, is it ok to always mention main guys in PR to let them know something was created or do they check PRs themselves, don't want to spam.

[tomastrajan]

Hi @Brocco , I have seen you did PR #8812 concerning schematics and collections, maybe you can have a look on this one too? Its about support for multiple collections per project.

[clydin]

@tomastrajan we monitor all the PRs but if you think a PR should be reviewed by a particular team member, there's no harm in mentioning them.

Also, thank you for contributions to the project and spending the time to help make the CLI better. Bug fixes and required features take priority so please don't feel discouraged if it takes a little while to hear back.

[bmayen]

Is this necessary in order to, say, use default Angular schematics and the new ngrx schematics in the same project?

[tomastrajan]

@bmayen @hansl No, you can use any collection with passing its name to collection flag like ng g someCustomSchematics --collection someCustomCollection which has to be installed in node_modules.

This PR is about being able to just run ng generate someCustomSchenatics without the need for collection flag. You could specify included collections in angular-cli.json in order of priority. This would be great for authors of single specific schematics so that you dont have to remember all the collection names every time you want to execute them. It would be enough to add them just once.

[bmayen]

Certainly much more convenient being able to define, only once in angular-cli.json, all of the collections you'll be using for a project.

I do think more thought needs to go into name collisions. Currently the first one encountered wins. This is fine when the intent is always to override, but we can't assume that. It's possible that two separate collections define foo, which are intended for entirely different purposes, and we'd want access to both of them. Otherwise we're assuming that any schematic name in a collection is reserved and will be overridden, potentially accidentally, if used by another collection.

[tomastrajan]

I see your point. The way this was intended to work is that you get override behaviour by default but you can always execute for specific collection in the same fashion like befote by passing --collection flag.

Besides from what I saw in ngrx schematics it seems to be the case that the way this is going is to use extends in schematics json declarations to pass through calls to underlying default angular schematics for stuff like component or service.

But this then only works nicely if you use ONE other schematics which delegates all the calls to underlying default. It doesnt help if you want to use more smaller / single purpose schematics from multiple libraries.

[bmayen]

But this then only works nicely if you use ONE other schematics which delegates all the calls to underlying default. It doesnt help if you want to use more smaller / single purpose schematics from multiple libraries.

This would be my main concern. It requires some knowledge of the implementation or behavior could be unexpected.

[Tiberriver256]

Just sharing my pre-conceived notion on how this was going to work. When I saw it was prefixed with @schematics, I thought it was going to be similar to how @types is managed by DefintelyTyped.

Package owners create a PR to merge schematics for their package into the main repo which is then auto-published after approval. This would solve the naming conflicts and it would be nice to just see them all available schematics listed in NPM under @schematics but I'm not sure how much overhead it really takes those Microsoft guys to manage it that way. Just a thought.

[hansl]

Closing this PR as it is too old and does not merge properly anymore. The work has been tracked locally in #12157 (which is a transfer from the issue from devkit).

It's something we want to support but needed to do some cleanup first. Now that 7.0 is out and that cleanup is done, we'll track it in our internal Jira and expect updates on the issue #12157.

[angular-automatic-lock-bot]

This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

_{This action has been performed automatically by a bot.}