Why use Grunt? In one word: automation. The less work you have to do when performing repetitive tasks like minification, compilation, unit testing, linting, etc, the easier your job becomes. After you’ve configured it, a task runner can do most of that mundane work for you—and your team—with basically zero effort.
The Grunt ecosystem is huge and it’s growing every day. With literally hundreds of plugins to choose from, you can use Grunt to automate just about anything with a minimum of effort. If someone hasn’t already built what you need, authoring and publishing your own Grunt plugin to npm is a breeze.
Installing the CLI
In order to get started, you’ll want to install Grunt’s command line interface (CLI) globally. You may need to use sudo (for OSX, *nix, BSD etc) or run your command shell as Administrator (for Windows) to do this.
This will put the
grunt command in your system path, allowing it to be run from any directory.
Note that installing
grunt-cli does not install the Grunt task runner! The job of the Grunt CLI is simple: run the version of Grunt which has been installed next to a
Gruntfile. This allows multiple versions of Grunt to be installed on the same machine simultaneously.
How the CLI Works
Each time grunt is run, it looks for a locally installed Grunt using node’s require() system. Because of this, you can run grunt from any subfolder in your project.
If a locally installed Grunt is found, the CLI loads the local installation of the Grunt library, applies the configuration from your Gruntfile, and executes any tasks you’ve requested for it to run.
To really understand what is happening, read the code. It’s very short.
Working with an existing Grunt project
Assuming that the Grunt CLI has been installed and that the project has already been configured with a package.json and a Gruntfile, it’s very easy to start working with Grunt:
- Change to the project’s root directory.
- Install project dependencies with npm install.
- Run Grunt with grunt.
That’s really all there is to it. Installed Grunt tasks can be listed by running grunt –help but it’s usually a good idea to start with the project’s documentation.
package.json file, and should be committed with your project source.
Gruntfile is comprised of the following parts:
- The “wrapper” function
- Project and task configuration
- Loading Grunt plugins and tasks
- Custom tasks
In the following Gruntfile, project metadata is imported into the Grunt config from the project’s package.json file and the grunt-contrib-uglify plugin’s uglify task is configured to minify a source file and generate a banner comment dynamically using that metadata. When grunt is run on the command line, the uglify task will be run by default.
Most Grunt tasks rely on configuration data defined in an object passed to the
In this example,
grunt.file.readJSON('package.json') imports the JSON metadata stored in
package.json into the grunt config. Because
<% %> template strings may reference any config properties, configuration data like filepaths and file lists may be specified this way to reduce repetition.
Like most tasks, the
grunt-contrib-uglify plugin’s uglify task expects its configuration to be specified in a property of the same name. Here, the banner option is specified, along with a single uglify target named build that minifies a single source file to a single destination file.
This extract of text has been used as a demonstration of the Astro Jekyll Theme. For more information on Grunt, see http://gruntjs.com.
Alexander has built a career and reputation by breaking the rules. Alexander's shoot-from-the-hip style has made him an effective enterprise architect and a slick character.