For the last nine months, I’ve been working with Ben and our team of fantastic contributors to modularize the Grunt codebase. Today, we’re happy to announce that Grunt v0.4 has been published to npm. Hold on to your hats, a lot has changed!
The primary focus of this version can be summarized by the venerable words of Doug McIlroy, “Do one thing and do it well.” We’re proud to say that this release is a major milestone on the road to fully embracing the Unix philosophy.
If you’re coming from Grunt v0.3.x, the most immediate difference you’ll notice is that we’ve removed all of the built-in tasks. Don’t worry, they aren’t gone—we’ve extracted them into officially maintained, standalone plugins. If you visit the plugin listing on our website, look for the entries with stars next to their names.
One of the biggest benefits of this change is faster iteration. It’s no longer necessary to ship a new version of Grunt for every minor plugin change! If jshint gets updated, for example, we can just release a new version of grunt-contrib-jshint.
Finally, with our core plugins separated, the barrier to entry for collaboration is lower than ever. If you’d like to get involved, please join us in #grunt on irc.freenode.net, or check out the Contributing guide and submit a pull request to add the feature you want.
This scaffolding task was always an odd-duck, and it really deserves it’s own project. So, we’ve broken it into a separate npm module, grunt-init, which can be installed globally with
npm install -g grunt-init. In the coming weeks, the Yeoman team will be replacing this task entirely, using their rails-inspired generator system. If you’ve authored templates for the init task, get in touch with them for details on how to make the conversion.
Another departure for those coming from Grunt v0.3.x is that Grunt itself no longer ships with a binary. Instead of installing Grunt globally, you now specify it as a development dependency in your project’s package.json file, along with any Grunt plugins you might be using.
In order to get the
grunt command, we’ve provided the grunt-cli tool, which should be installed globally. The sole purpose of this tool is to load and run the locally installed version of Grunt, and good news—it will work with every version from 0.3x and higher.
There has been considerable confusion in the community about global vs local installation of packages. We recommend reading this excellent article by @isaacs for more information about why it is desirable to install things locally when using node.
Gruntfiles are now more powerful than ever. We’ve been hard at work implementing community requests, and thanks to everyone’s feedback, the results are fantastic. Here are a few of the major additions:
Need to run the same task on more than one set of files? Say goodbye to duplicative configuration, options can now be defined at the task level—they’ll automatically apply for all of your target file groups. If needed, you can override them individually. Check out our documentation for more details.
Need data from
package.json for your build process? How about a YAML file? Not a problem, just load it into your configuration and apply it anywhere you like. Check out our documentation for more details.
Just to whet your whistle, here are a few handy methods we’ve added to make writing tasks a cinch: file.isPathInCwd, file.doesPathContain & file.arePathsEquivalent. There are far too many additions to list in this introduction, please see our migration documentation for a full rundown.
Grunt 0.4 ships with a flashy new website. We’ve got reams of documentation, and helpful tools for discovering the perfect plugin for your project. Check it out at gruntjs.com!
If you think Grunt is great now, just wait until you see what we have in store for the next major version. Here’s a glimpse of what you can expect next:
Grunt has made it easier than ever to select, negate and map your project files from one location to another—complicated globbing patterns need not apply! We’re so happy with the power this system affords that we’re going to extract it into a standalone library so anyone can use it.
Sharing values across multiple configuration files is a breeze with Grunt’s templating system. Soon, you’ll be able to unleash Grunt’s declarative power anywhere you need it—we’re turning this system to a standalone npm package as well.
Don’t like Grunt’s configuration syntax? Go crazy and write a middleware to convert your format to ours. Maybe we’ll love it and decide to make it the default.
When you upgrade to v0.4, chances are strong you’ll run into some tasks that don’t support it yet. We know this sucks, and we’re working with plugin authors to get the ecosystem up to speed as quickly as possible. Long term, we’re going to solve this problem entirely. Here’s how:
Grunt v0.5 will ship with support for a new plugin format called node-task. It defines a stateless, promise-based, event emitting API that doesn’t depend on Grunt. It has a real-live spec, and the Grunt team is working with the front-end developer community in the hopes that compliant modules will be compatible with every task runner under the sun. When it’s done, it will ship with a test suite that anyone can use to build their own tasks.
Phew, you made it to the end—thanks for hanging with me. If you’d like to know more about Grunt, please read our Getting Started Guide, and check out all of the ways you can configure your tasks, too.
This entry was posted by Open Source.and on February 18, 2013 in