Skip to content
This repository was archived by the owner on Apr 4, 2025. It is now read-only.

feat(schematics): specify multiple default collections #249

Closed
jeffbcross opened this issue Oct 31, 2017 · 12 comments
Closed

feat(schematics): specify multiple default collections #249

jeffbcross opened this issue Oct 31, 2017 · 12 comments
Assignees

Comments

@jeffbcross
Copy link

Bug Report or Feature Request (mark with an x)

- [ ] bug report -> please search issues before submitting
- [x] feature request

Area

- [] devkit
- [x] schematics

Desired functionality

It'd be nice to have multiple collections configured in my CLI project instead of a single default collection. I.e. I'd like to have a project that gives preference to nrwl/schematics but will fall back to angular/schematics if I try to generate something not provided by nrwl/schematics. This would make it easier to publish many focused schematics without requiring the user to specify the collection each time they're generating something new. My naive suggestion is to change the .angular-cli.json schema from a single collection value to a cascading array of collections like so:

"defaults": {
  "collection": "nrwl/schematics"
}
"defaults": {
  "collections": [
    "nrwl/schematics",
    "angular/schematics"
  ]
}

Then when calling ng generate, schematics would use the first collection that provides a matching schematic.

This issue seems cross-cutting between CLI and Schematics, so I thought this repository was the most appropriate place to open it, but lmk if I should open it on angular/angular-cli.

(This may seem similar to #34, but it's more focused on end user experience than schematics author experience).

@tomastrajan
Copy link

tomastrajan commented Dec 2, 2017

Hey guys!

I was able to implement this in @angular/cli exclusively and was rather a small change. Basically just retrieving of schematics property as array and filtering for first matching schematics / collection pair.

Still have to look into tests though. Also it is possible that you might have had plan for other solution so please let me know.

Also check following screens for the new behavior.

Display help for ng generate with all available collections and their schematics

schema1

Display detailed help for particular schematics (first matching schematics / collection pair wins so the order in schematics property in angular-cli.json matters)

schema2

Generate items using schematics from different collections (again, first matching schematics / collection pair wins so the order in schematics property in angular-cli.json matters)

schema3

@tomastrajan
Copy link

Hi @jeffbcross @hansl

There is now open PR with initial working implementation of this feature on angular/angular-cli repo. Please let me know if its a good base to make this work.

Cheers 🍺

@myspivey
Copy link

Would like this as well.

@Hotell
Copy link

Hotell commented Mar 17, 2018

any update on this?

this is totally needed for great DX.

Enforcing users to write --collection @my-foo-bar/super-schematics all the time when switching between collections is super annoying...

thx

@tomastrajan
Copy link

From what I have seen in nrwl/schematics currently the way to go is to extend @schematics/angular in your custom collection.json.

That way you don't have to delegate every schematic manualy, provide default ones out of the box and add custom on top of that.

Thr big downside is that this leads to ONE custom collection set as a new default for angular-cli.json.

This unfortunatelly doesn't support "multiple small focused collections from different authors" use case. 😞

@Hotell
Copy link

Hotell commented Mar 17, 2018

Yeah I know, but this is to restrictive and repetitive and hard to maintain overall.

Maybe, just guys, can you please give some statement or so, why @tomastrajan PR wasn't accepted yet or what are the plans ? I know we are all super busy, but would appreciate some response.

thank you 🖖

@clydin
Copy link
Member

clydin commented Mar 20, 2018

Schematic collection extension supports 1 or more schematics with the last taking precedence. The currently envisioned concept is for a custom collection to be placed within the project and that collection to extend from any other schematic collections with the option to directly define other custom schematics if desired. As the schematic extension logic is fully implemented within the core of the schematics system, having similar but repeated logic within the CLI itself represents a maintenance and supportability concern.

@clydin
Copy link
Member

clydin commented Mar 20, 2018

For reference, the collection extension PR: #398

@james-schwartzkopf
Copy link

james-schwartzkopf commented Mar 23, 2018

I think I like that idea long term, at least assuming there will be an easy command for the user to run to add a schematic collection without needing to know the details of collection.json (maybe handled by ng add my-schematic?).

Short term I dislike that every project is adding @schematics/angular to their schematic collections. I'd rather leave it up to the user to compose the schematic collections that make sense for their project. I think it's likely to lead to a mess as users pressure package authors to extend more and more external collections so they can have one collection to rule them all.

I know no one likes to give timelines, but I can't help but ask, any idea on a timeline for this (custom collection in the project)? Is it planned for any release yet? Any issue to track?

@hansl
Copy link
Contributor

hansl commented Mar 23, 2018

custom collection in the project

You can already do that.

@james-schwartzkopf
Copy link

Yeah, but there's none there by default in a project created by ng new. So everyone's adding @schematics/angular to their schematic collections since it doesn't seen to be straightforward how you add a collection without having to use --collection either for the new collection or for @schematics/angular.

@alexeagle
Copy link
Contributor

This issue was moved to angular/angular-cli#12157

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

9 participants