text: Support for third-party generator blueprints · Issue #2618 · angular/angular-cli · GitHub
  Support for third-party generator blueprints #2618
  mischkl opened this issue Oct 10, 2016 · 19 comments
  priority: 3 (nice to have) type: faq type: feature
  mischkl commented Oct 10, 2016
  I actually have no experience with this feature on Ember, but I see that ember-cli has it and I think would be a great boon to angular-cli: the ability for the user to generate code from their own blueprints, or to use third party ones installed via npm. I guess this could be part of the "add-ons" functionality I've heard rumors about. ;)
  Example use cases would be generating routes for UI-Router, generating stores for ngrx or Redux, generating GraphQL endpoints for use with angular2-apollo, generating style guides or other kinds of documentation, and on and on - the imagination of the GitHub community would be the limit. :)
  Note: I realize Yeoman can already accommodate some use cases, but it's not really designed to deal with existing projects, it can't use/extend the angular-cli API, and in all likelihood anyone using angular-cli won't give it a second look.
  This is on our radar for the addon system actually.
  filipesilva added type: feature priority: 3 (nice to have) labels Oct 10, 2016
  @filipesilva awesome, glad to hear it. :)
  christopherthielen commented Jan 23, 2017
  I'd like to add support for routing with ui-router-ng2. What are the current ideas for how third party support might be implemented?
  filipesilva commented Jan 23, 2017
  Heya @christopherthielen! There isn't a public plan available for third party blueprints yet. It's mostly a post 1.0 concern at the moment.
  I think the best you can do currently is provide some instructions on how to modify a newly generated project to use ui-router-ng2. Let me know if you have any trouble doing it.
  filipesilva added the type: faq label May 22, 2017
  filipesilva self-assigned this May 22, 2017
  Custom Templates for Each Type of Component #3549
  Feature request: Support mocha #4071
  ng generate page-object #5584
  Allow to pass a custom filename for component and module #6420
  CesarD commented Aug 10, 2017
  Is it being actively worked on or still in the drawer?
  Support for custom blueprints was added in #7090, available in 1.4.0-beta.1 and up. It's based on @angular-devkit/schematics: https://github.com/angular/devkit/tree/master/packages/schematics/angular.
  We don't yet have documentation and examples of how you can make your own but @Brocco is working on it.
  filipesilva closed this Aug 21, 2017
  CesarD commented Aug 21, 2017
  Any schedule you might be working on for the release of a stable 1.4.0 version? Perhaps within the next 30 days? Just curious.
  filipesilva mentioned this issue Aug 30, 2017
  Feature Request: Custom Blueprints #2377
  filipesilva commented Aug 30, 2017
  @CesarD yeah most likely. It's in rc.2 right now so it shouldn't take long at all.
  kerihobo commented Mar 23, 2018
  Hi is there any further news on this? I would love to be able to automate my new components being added to my router and also to set some defaults to my generated constructors, I would also like every component to be able to utilize my main stylesheet.
  bmayen commented Mar 23, 2018
  Support for custom blueprints was added in #7090 , available in 1.4.0-beta.1 and up. It's based on @angular-devkit/schematics : https://github.com/angular/devkit/tree/master/packages/schematics/angular .
  CesarD commented Mar 25, 2018
  Documentation on how to use it? Anywhere?????
  kerihobo commented Mar 26, 2018
  Yeah plz.
  k-vekos commented Jan 23, 2019
  CesarD commented Jan 23, 2019
  In this time I have found a few articles about how to make schematics for Angular:
  https://medium.com/@tomastrajan/%EF%B8%8F-how-to-create-your-first-custom-angular-schematics-with-ease-%EF%B8%8F-bca859f3055d
  k-vekos commented Jan 28, 2019 •
  I want to create a custom schematic for my Angular SPA application. Right now I only really want to modify the existing schematic for "component", and only to alter the HTML and TypeScript template and I only need it to be available inside the scope of this one SPA project, so I don't need a library necessarily.
  @CesarD your articles go over making a custom schematic collection but both seem to imply creating this schematic collection as a separate library. I'd rather not have to build another library in addition to my SPA. If possible I'd rather have the custom schematic be part of my SPA project/code. As it stands I would need to create a schematic collection somewhere in my project repository, check in the source, then when a developer wants to develop with the app they need to build the schematic project, then npm link it. This doesn't sound like an ideal workflow.
  CesarD commented Jan 28, 2019
  @k-vekos well, it actually is a library to add. Think about it as a library for the angular-cli. You need to have it installed to later use it on any angular project you want.
  Also, any schematic needs to live inside a collection, so that's why you need to start with the collection.
  AFAIK, schematics cannot be made to run within an app. And I don't think it would make sense otherwise, as they are not necessarily part of an app, but as something aside of it to just generate some of its components.
  @CesarD it makes perfect sense to me that they would be beneficial if it were possible to scope them to a single application. Simply being able to add boilerplate code when adding a new service or component to an existing application would be a use case for schematics.
  Actually, the author of one of the articles you linked would seem to agree with me:
  CesarD commented Jan 29, 2019 •
  Yes, that is exactly their purpose, and that's why I also wanted them.
  That said, they still operate outside of the scope of the app, at a CLI level.
  When I wanted to make schematics, I was looking forward to be able to make schematics that I could use in several apps to keep coherence among my projects (services made the same way, CRUD modules made the same way, security implementation with OIDC, etc), so I could use and reuse the same patterns. I think that's the main purpose of schematics.
  Anyway, it's just my point of view and perhaps the one used by the team when designing the schematics.