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.

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.