Skip to content

Instantly share code, notes, and snippets.

@sindresorhus

sindresorhus/yeoman-future-proposal.md

Created October 27, 2012 16:02
Show Gist options
  • Star 2 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save sindresorhus/3965166 to your computer and use it in GitHub Desktop.
Save sindresorhus/3965166 to your computer and use it in GitHub Desktop.
Download ZIP
Yeoman.future proposal rev2
Raw
yeoman-future-proposal.md

Yeoman.future proposal rev2

tl;dr

  • Yeoman will continue to offer a single catch-all command for our workflow (including building with Grunt and package management with Bower)

  • We will make it very explicit about the tools we use and ensure it's easy for developers to find documentation/support for them (e.g from homepage)

  • We will also do our best to implement Yeoman as an even thinner wrapper around these tools, so moving to using Grunt alone is next to no effort

  • Auto-update will shift to only being a notification about available updates.

  • Generators will use Bower for dependencies available in the registry and we will recommend pushing boilerplate projects (e.g Angular seed) to Bower as well (optional)

  • We will move towards Gruntfiles being more static and they will contain information about the build tasks/profiles you wish to use (which they should have from the start). This will make it possible to switch to use grunt directly with minimal changes.

  • Good ideas have been suggested for the generators in yeoman-dev. We will consider implementing some of them as we modularize the scaffolding system into its own project

What does this practically mean?

The main difference is that we'll now create everything statically up front, by that I mean, the generators job is to scaffold out the project with Gruntfile (with generator specific tasks), package.json and every dependency you need based on some prompts. Then it's grunt's job to handle the task execution. This will make your project 100% grunt compatible and remove the need for the hidden magic. Everything about how it works will be visible in the Gruntfile and you'll be able to change whatever you want, add tasks, etc. This is a HUGE win! Our generators will add in the tasks it needs as dependencies, but users are free to change those.

Current generators will be split up into separate repos and owned by interested maintainers. They will be distributed through NPM using a naming scheme tbd, eg: generator-backbone, yeoman-backbone or something.

Insights will rewritten in Node.js as a generic module any project can use. Atm the API is private so only whitelisted usage allowed, but hopefully that will be available soon. Ben would be open to including it in grunt as a opt-in. Need to figure out how that will work. Big benefit will be to get valuable insights into how users are using grunt, and could be a valuable source for further improvements to grunt. I will probably work on that module. We'll of course still keep it in Yeoman.

Benefits

We don't do these radical changes lightly, but there are some huge benefits for doing so:

  • Dependency tree will be massively reduced by only including the required dependencies for a specific generator. Because Insights is being rewritten in Node.js and Compass requirement is now generator specific, users might no longer need Python/Ruby/Compass.

  • Since the whole build process is transparently viewable in your Gruntfile, it's easy to change paths and tasks. Users will feel in control and it will remove most of the complaints about Yeoman's constraints.

  • Yeoman will be completely independent from Grunt releases.

  • All the users project dependencies will be local.

This change will solve a significant percent of our current open tickets and will make Yeoman even more awesome by letting us focus on the important parts instead of being a support center.

Generators

Generators will have its own discussion.

Tasks

  • compass task is already upstreamed as grunt-contrib-compass
  • html task will be rewritten and upstreamed as grunt-contrib-htmlmin.
  • img task will be rewritten and upstreamed as grunt-contrib-imagemin
  • server, grunt-contrib is interested in having a grunt-contrib-livereload task. We might be able to persuade the author of Livereload to do it. Prior art: grunt-reload.
  • manifest task will removed. Its usefulness is severely constrained by just mindlessly generating a manifest from a single HTML page. We'll rather recommend but not include grunt-manifest.
  • bower task will be extracted.
  • rev task will be removed. We'll use grunt-md5 instead.
  • css, not sure yet, we might keep it, since https://github.com/gruntjs/grunt-contrib-mincss doesn't cover all of it's use-case.
  • rjs task will be replaced with grunt-contrib-requirejs.
  • misc and tar will probably be included in a generic yeoman lib task or something.
  • usemin, should be made more generic and extracted as a standalone grunt task.

Finis

Everything written here is very much up for discussion, and we do encourage you to do so.

We're also looking for owners for our different generators. If you're interested or want to know more, talk to me.

@sindresorhus
Copy link
Author

Discussion: https://groups.google.com/d/topic/yeoman-dev/cMk1rBP4OA4/discussion

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment