Repository navigation
Collection Extension / Merging #34
Description
Sometimes you want to reuse schematics from another collection as is. For example, someone could want to implement a collection that is the exact same as the angular one (same schematics), but changes only 1 schematic. All the others should be the same. Or maybe a company wants to have a default collection on their CLI but have that collection include schematics from a number of other collections.
A proper system should allow merging of collections, with some resolution if there's a collusion, and a list of schematics that it implements itself (might be empty). As an example (the schema is just an example):
{
"$schema": "http://schema.angular.io/schematics/collection/2",
"name": "my-com",
"description": "My Company default collection, containing all schematics that are used normally",
"extends": [
"@schematics/angular",
"@my-company/schematics-base",
"@my-company/schematics-pages"
],
"schematics": {
}
}This would include the base angular schematics, the base my-company schematics and the pages schematics. This helps with separating development of each of those, while the end user can just install and use one collection. The schematics are merged, with names being overridden by pages, then base, then angular.
Activity
mrjmd commentedon Jul 26, 2017
This is a key feature for my use case. The ability to build on top of existing collections and modify them as needed will open up a ton of possibilities, I'm looking forward to playing with this.
bmayen commentedon Sep 24, 2017
Just came here to add a feature request for exactly this. Nice to see it already on the radar.
My main concern with not having this functionality is that if our company creates it's own collection copied from the default, even if it's just to change one minor thing, we're committing to potentially a lot of additional maintenance work to ensure we're always in sync with the latest and greatest updates from here. And since we likely wouldn't commit to that additional effort, we need to decide on either all in on the default "CLI way" or all in on no longer staying current with it. Neither option is ideal.
We're currently faced with a similar problem with the CLI webpack "eject" approach, but I digress.
hansl commentedon Sep 26, 2017
@bmayen we support
extendsright now between collections, and even without it you could have defined a factory that just forward the call to the extended collection.You can safely depend on the Angular collection, and extends it to bring those schematic in yours. You could always extend a schematic by using it and then modifying its content, so what you describe was already possible without this issue (it's a core feature and a goal of schematic to be extendable and composable).
Just to reiterate: he only thing that's valid for this issue that's not already possible is to have "extra" schematics from the extended collection, without having to redefine or extend them in your own collection. For example, if you want to provide the original
componentfrom your collection without any change, you have to add a{ "schematics": { "component": { "extends": "@schematics/angular:component" } } }to your
collection.json. If we add a new schematic to@schematics/angularyou won't get it for free. This is what this issue is about, but I think for most people they'd want to have some steps before exposing an extended collection.This issue is bound to fix that. A use case that we're looking at is adding a copyright notice to all files created in a collection. It doesn't make much sense to rebuild all schematics provided by
@schematics/angular, it's really about extending the@schematics/angularcollection and chaining an additional rule to it that gets run everytime someone generates.bmayen commentedon Sep 26, 2017
Ah, gotcha. Thanks for the clarification and all the amazing work!
bmayen commentedon Dec 17, 2017
@hansl, could you help clarify something for me?
In my original comment I mentioned "if our company creates it's own collection copied from the default, even if it's just to change one minor thing, we're committing to potentially a lot of additional maintenance work to ensure we're always in sync with the latest and greatest updates from here". But you indicated that this wasn't a problem since we can extend existing collections.
But let's say we want to slightly modify some files output by default
application. I know I can extend@schematics/angular:applicationin my collection in order to get that default functionality, but is it currently possible to both extend it and provide custom functionality? For instance, if we wanted to add a custom README to the defaultapplication.If I'm understanding you correctly, that's what this issue is about. Any idea where this might fall on the timeline?
hansl commentedon Dec 18, 2017
You can create a collection, depend on
@schematics/angular, implement your ownapplicationschematic that callsexternalSchematic('@schematics/angular', 'application')then chain it with your own rule that adds to the README.What you're describing is the goal of this feature. No idea on timeline.
bmayen commentedon Dec 18, 2017
Thanks for the clarification!
josuerios commentedon Jan 17, 2018
@bmayen can you provide a example, i'm following these instructions and related issues and is not working for me, thanks in advance