Musings on Yeoman.next

thoughts.md

Yo.next stream of thought

We currently have an on-going design doc walking through our ideal implementation of Yeoman.next - a system of easily composable generators. Given the complexity of that task, we're likely going to need to break that proposal down into several sub-specs/tasks that we gradually introduce as generator system features. This gist is to mostly collect ideas that define how yo.next generators differ from what we have today.

The hope is that definitions will provide us some guidance when it comes to actually prototyping this system.

Atomic generator responsibilities

Perhaps it would be useful to define what an ideal atomic generator would do for a project. What are the responsibilities it should own?

yo bootstrap

1. Prompt the user for a flavour of Bootstrap they want to use. Install it via Bower to their app/bower_components or wherever.
2. If an index.html file is present, wire up the file with a local reference to Bootstrap CSS?
3. If a Gruntfile is present, wire up related tasks for Sass compilation, livereload? Is that too far-reaching?

It almost seems like the task of wiring up the dependency could be delegated to grunt-bower-install, leaving 3. to be done by another process. See below for more on this.

Generators for specific Grunt tasks?

Does it make sense for individual (popular) Grunt tasks to have their own micro-generators for scaffolding? For example..

yo contrib-imagemin

• Fetch grunt-contrib-imagemin from npm
• Install in the local project and add refs to your package.json
• Scaffold up your Gruntfile (if found) with basic configuration for the task
• Alternatively, prompt the user about this configuration (paths, etc). If so, make it so that we parse rather than anything different having to be done on the Grunt side

What is a Yeoman.next generator?

If we did end up creating generators for specific grunt tasks, a Yeoman generator could be composed of:

• Grunt task configuration scaffolds
• File and dependency scaffolds

Taking a look at say.. generator-webapp. One could imagine it being made up of:

• generator-h5bp
• generator-bootstrap
• generator-gruntfile (maybe)
• generator-contrib-imagemin
• generator-contrib-cssmin
• generator-contrib-watch
• generator-contrib-clean
• generator-contrib-modernizr
• generator-contrib-coffee
• generator-contrib-concurrent
• generator-contrib-newer

(or similar). This gives us a finely grained ecosystem of scaffolds that anyone can then go and use to create their own "composed" generators. Part of me wonders if this whole atomic Grunt task generator concept could be automated by having task authors include the config information in their repo (I mean..most already have a sample Gruntfile), but if that's too much of an ask this could potentially help define the level of composability we want to offer.

Passing data between these generators

One of the current limitations of this idea is how we actually pass back data, state and modified file information from one generator to another. I can't currently think of anything better than the intent system Simon proposed for achieving this. The generator system itself needs to support data passing, which it does not at present (afaik).

I do wonder however how much information passing will practically be needed. Most Grunt scaffolds could ascertain (I think) what they need directly from the Gruntfile and current working directory. The file conflict resolver would handle overwrites.

Passing custom configuration to Grunt task scaffolds

Another problem with this idea is that it assumes a generalizable set of configuration can be written by each Grunt task scaffold that is relevant to each project. That isn't the case. We would almost need a way to programatically pass configuration information from within a consuming (parent) generator to a generator it calls out. For example, path information, ideal settings (e.g for JSHint) and so on. Short of manually updating the Gruntfile/parsed version of it, unsure of how to cleanly handle this.