Allow users to combine generators. More decoupling/composability.

[alexkreidler]

This is a long issue/feature request, so

TL;DR

Users should be able to combine generators how they want so they can create scaffolds exactly how they want with the tools they need, even if a premade generator with that combination doesn't exist.

The problem

I love Yeoman, but one problem I find with the ecosystem of generators that we currently have is that each generator has their own choice of:

• package manager (npm, yarn, etc)
• build tool (grunt, gulp, webpack, broccoli, brunch, parcel)
• backend framework (express, hapi, etc)
• frontend framework (reactjs, angular, vue, etc).

All of these choices are more often than not baked into the generator.

If the user wants a specific combination of these items, they have to:

• hope that someone has already made a generator with that combination
• hope that a generator is configurable to that combination- if the generator does not have the combo they want: start with an existing one and then modify it manually after the fact, taking additional effort and defeating the point of a generator.
• make their own generator (which would help them for the future, but not in the moment)

With more and more choices and options for each item/tool on a developer's list, the number of combinations will grow exponentially and the current limited configurability of generators will not cut it.

Users will want to be able to combine generators how they want.

I do recognize that yeoman has a way for each generator to provide options to configure it. However, this means that the burden of providing the options and configuration lies on the generator developer, leading to most generators just ignoring the options or only providing limited options.

The experience

I propose a way for users to combine more simplified generators how they want. For example, a user could combine:

• A React generator (with options for Redux)
• with a Brunch builder/bundler
• with an Express server generator

This would be a powerful feature that could take Yeoman to the next level.

People could still package these combinations into one generator as well with a prescribed workflow, like React+Redux+Webpack, but users would have the flexibility to replace components.

Obviously it would be difficult if not impossible to merge two of each type (e.g. React and Angular or Webpack and Grunt)
It would be unlikely any user would want to do that.

Implementation

I have some ideas for implementing this, but they may be bad.

Option 1
Keep the API the same.
Run each generator, then merge them together. Just merge file trees, and have special merge methods for important files like package.json
Then if there are other conflicts, present them to user and let them keep one or another version, or delete it, or just append one to another (e.g. for a .gitignore or .dockerignore

Pros:

• No (or minimal) API changes for generator developers
  Cons:
• Very hacky, may be weird bugs with merging file trees or files
• Bad UX for merging if the user has to figure out what to do
• Will take some amount of specific coding for each language and important files

Option 2
Change/extend the API so each generator provides all information needed to successfully combine it with other generators.

For example a webpack or Brunch generator would explain to the API that

1. It needs to be added to package.json, and possibly modify the scripts section
2. It needs a webpack.config.js or a brunch-config.js in the top-level directory
3. It needs to add a section to the README.md

This could happen in the templates, with a comment or directive saying how files should be merged.

Another example:
An express generator merged with a React generator
Each generator should provide an alternate path in case the path they're using (src) is already in use

Another option
Introduce the idea of roles so

1. Users cannot combine two generators with the same role (e.g. can't combine Angular and React because they are both frontend-frameworks)
2. Each role could have a path (e.g. ./backend or ./frontend

One other idea is to have generators describe their compatibility with other generators.

If the API were changed to be more component/module focused, this could also possibly make it easier on generator developers if there were a set of well-tested components that they could use to build their generators. This is described here: yeoman/yeoman#1597

These implementation brainstorms are very rough and none of them are great ideas. However, I think the core idea that users can combine generators how they want is a great idea that would make Yeoman 10x better and more useful.

Let me know what you think. I appreciate any feedback anyone has.

[SBoudrias]

Hey, we touched on this issue a long time ago around this ticket: #345

I think overall, composability is pretty complicated and it's really hard to ensure many generators or enough of them can work together without crashing/overwriting each other and generating a working output. I wouldn't want to discourage you from trying something like this; but from my experience, this didn't work really well.

[github-actions]

This issue is stale because it has been open 15 days with no activity. Remove stale label or comment or this will be closed in 5 days

[alexkreidler]

Just a quick update: I think a lot of similar tools in this space are moving gradually in that direction, most notably Plop, the "micro-generator framework". There's also Hygen which is in some ways even more minimal.

However, although both of these have

1. emphasized smaller reusable generators/templates
2. enabled modification of existing files

they still haven't figured out a way to compose multiple generators/templates idiomatically. If I want to generate a project based on React, Brunch, and Go for example, I'd still have to either find an existing generator or write one for each, and then call them separately.

However, these new micro-generators don't really have a centralized way to find and use the generators like Yeoman does, so that's one disadvantage. They encourage you to write them on your own, in your project, with your team.

[github-actions]

This issue is stale because it has been open 15 days with no activity. Remove stale label or comment or this will be closed in 5 days

[github-actions]

This issue is stale because it has been open more than 45 days with no activity. Remove stale label or comment or this will be closed in 15 days