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.
What is a Yeoman.next generator?
If we did end up creating generators for specific grunt tasks, a Yeoman generator could be composed of:
Taking a look at say..
generator-webapp
. One could imagine it being made up of:(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.