Collection Extension / Merging

[hansl]

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.

[mrjmd]

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]

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]

@bmayen we support extends right 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 component from 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/angular you 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/angular collection and chaining an additional rule to it that gets run everytime someone generates.

[bmayen]

Ah, gotcha. Thanks for the clarification and all the amazing work!

[bmayen]

@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:application in 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 default application.

If I'm understanding you correctly, that's what this issue is about. Any idea where this might fall on the timeline?

[hansl]

You can create a collection, depend on @schematics/angular, implement your own application schematic that calls externalSchematic('@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]

Thanks for the clarification!

[josuerios]

@bmayen can you provide a example, i'm following these instructions and related issues and is not working for me, thanks in advance