Roots generator for yeoman's yo

Hi guys,

I’m currently working on a yo generator that scaffolds a Roots fresh install, packed with some bonuses.

Themify : GitHub - Chmood/generator-wordpress-themify: A modular Wordpress theme generator, based on Roots

It’s meant to be very modular, and supports both less and sass, along with optional image minification, coffeescript compilation, css autoprefixing and javascript unit tests, plus some example files.

I had the crazy idea to make almost ALL features opt-out-able : you can start with plain css, no boostrap, no modernizr, and even no Roots! It still generates a valid theme.

This generator also offers a true build task in the gruntfile, in order not to bloat the production theme with development source files (less, sass…), nor with node_modules folder (which can be a heavy beast!). It outputs an optimized build of the project in another directory, packing only what’s needed.

Other modifications include :

  • using bower package manager and it’s bower_components directory (for jQuery, Boostrap, Modernizr…)
  • a bit of revamping on js/css files naming scheme (now using main.js and main.css as compiled files, both in dev/prod themes)
  • a bootstrap setup that allows to override the framework AND to update it with bower
  • probably other things I can’t remember…

All the rest (especially PHP files) remains the same wonderful Roots we all love.
(Exception made of /lib/scripts.php : modded paths + templated by yo with conditional modernizr support)

Well, this generator is still in early stage, and needs much bug-fixing and beta-testing. But it’s more or less functional, so I thought you folks could be interested in giving it a try!

Any comment, help, feature request or bug report (via github issues) would be highly appreciated.
Grunt/yo/roots ninjas are welcome too, come and see how terrible I am at git!

Is a Roots generator a good idea? How would you improve this one? Which tasks do you often add to your Gruntfile.js when theming with Roots?

3 Likes

This looks awesome, going to dig into it some more soon but just wanted to say that something that’s been on our TODO list for a while is to create a Roots generator that would:

  • allow you to choose between LESS/Sass for Bootstrap
  • allow you to choose between Bootstrap, Foundation, Pure, (etc.) or no framework (while also being able to select a preprocessor of your choice)

We’ve made zero progress on that so far :smile:

Glad to know you had such plans in the tubes! I guess it would be handsome for the end-user to customize the Roots starter kit according to his/her real needs. And it’s definitely feasible, with moderate effort.

Some thoughts about it :

  • Switching to sass (or plain css, or even Stylus) is a no-brainer, hail to yo. Just another grunt task, and another bootstrap’s port repo in bower. Well, and some '<% if (preproCss === 'sass') { %>' here and there!

  • Support for multiple css frameworks needs more refactoring of the presentational classes generated by Roots templates/functions (and probably others things I’m not aware of yet).

  • Combining both (choice of the preprecessor AND of css framework) leads to some restrictions when the user answer to prompt : when opting for Less for instance, Foundation wouldn’t be available (no existing port). Not a big deal…

And thanks Ben for your interrest :blush:

Very cool! Watching on github.

Can you explain the workflow a little more? Is it that you essentially create two themes, one dev, one production. Work in dev locally and package (grunt dist) into your production theme? My local WP instance points at dev and live WP instance points at production?

If I’m using git to manage all of this, how would this keep /node_modules/ and similar off of production? Manage my dev theme as a separate git repository?

Hey Will, interresting questions!

App and dist

You’re true, two themes. Call them Appy and Disty if you like :smile:

  • App is where the work goes on. Think readable source files. Your development playground. Should be versionned on git.

  • Dist is just an optimized snapshot of App, at a certain moment. Ready to be send in production. Think of it as a binary (like a .exe) : you cannot modify it anymore, but you can keep older versions of it (or even regenerate it).

Separation between ‘app’ and ‘dist’ is in the grunt genetic for a while (I mostly drain inspiration from yo generator-webapp). They even promote a hidden .tmp directory. In short :

  • project/
  • app/ (theme assets and sources)
  • dist/ (optimized minimal build)
  • project files (git things, package.json, bower.json…)

Roots uses a simpler model :

  • project + app + dist
  • project sources + optimized files + assets + project files…

WTF in my git repo?

Keep this in mind :

  • npm (and package.json / ‘node_modules/’ dir) provides the local grunt tasks you need to work on the project. Only used in development phase.

  • bower (and bower.json / ‘bower_components/’ dir) provides the components that your project needs to work (jQuery, Bootstrap…). Needed in production, but only parts of (not the whole github repo of bootstrap is needed, only less files, javascript plugin, and some fonts).

  • Both npm and bower are package manager, allowing you to quickly fetch, use, update, and solve dependencies of complex software components. Their “content” shouldn’t be included, as their configuration files permit to fetch it with a fingersnap!.

Simple rule of thumb : your git repo won’t need neither node_modules nor bower_components directories. But DO provide package.json and bower.json files, so users will be able to scaffold the magic with npm install and bower install.

And : that’s precisely what a yo generator do : install npm and bower stuff after having configured the new dev ecosystem!

The Roots’ .gitignore file already neglects node_modules/ dir, mine also discard bower_components/.

And do use git to only version your (dev) project. Eventually keep tracks of older ‘dist’ builds.

Hope it helps!

Thanks very much @Chmood. I’ll keep my eye on it - good luck.

@Chmood Very cool generator indeed. I just installed it (had some trouble linking but it’s all good now).

I haven’t really looked into it but everything seems to work properly now. Just a question though, there is no LiveReload plugin included right?

Well thanks again for the work put in so far, i’ll be on the lookout for updates!

Hi @jamraket !

I really appreciate you took the time to check it out, considering installation it’s not (yet) very user-friendly.
You made your way through it, congrats!

And you’re right, the livereload plugin isn’t shipped with the generator, you’ll have to install one that fits in your browser. I use this one for Chrome, which seems to be available for Firefox and Safari too (not tested).

Once the plugin is activated in the browser, it acts as a server (there’s a port setting in Gruntfile.js) listening to grunt (read nodeJS) requesting a page reload. Which happens anytime the watch task detects a change in the files it monitors.

Or sort of, cause well, I’m still not sure of how it works, but the job is done :blush:

Say goodbye to the F5 key for me!

This looks killer. I can’t wait to start using it. Going to try and read through some of this when I get a sec.