Grunt Cookbook

Grunt Cookbook

By : Jurie-Jan Botha

Buy this Book

Grunt Cookbook

By: Jurie-Jan Botha

Buy this Book

Overview of this book

<p>A web application can quickly turn into a complex orchestration of many smaller components, each one requiring its own bit of maintenance. Grunt allows you to automate all the repetitive tasks required to get everything working together by using JavaScript, the most popular programming language.</p> <p>Grunt Cookbook offers a host of easy-to-follow recipes for automating repetitive tasks in your web application's development, management, and deployment processes. This book will introduce you to methods that can be used to automate basic processes and your favorite tools. By following the recipes, you will soon be comfortable using Grunt to perform a wide array of advanced tasks in a range of different scenarios.</p>

Grunt Cookbook

Credits

About the Author

About the Reviewers

www.PacktPub.com

Preface

Free Chapter

Getting Started with Grunt

Introduction

Installing the Grunt CLI

Setting up Grunt in a project

Installing a plugin

Setting up a basic web server

Watching files for changes

Setting up LiveReload

Processing only changed files

Importing external data

File Management

Introduction

Copying files

Compressing files

Creating symbolic links

Concatenating files

Fetching a single URL

Fetching multiple URLs

Templating Engines

Introduction

Rendering Jade templates

Using data in a Jade template

Using custom filters in a Jade template

Compiling Jade templates

Compiling Handlebars templates

Compiling Underscore templates

Using partials in Handlebars templates

Wrapping Jade templates in AMD modules

Wrapping Handlebars templates in AMD modules

Wrapping Underscore templates in AMD modules

Wrapping Handlebars templates in CommonJS modules

Altering Jade templates before compilation

Altering Handlebars templates before compilation

Altering Underscore templates before compilation

Generating CSS and JavaScript

Introduction

Compiling LESS to CSS

Compiling Sass to CSS

Compiling Stylus to CSS

Compiling CoffeeScript to JavaScript

Compiling LiveScript to JavaScript

Generating source maps for LESS

Generating source maps for Sass

Generating source maps for CoffeeScript

Defining custom functions with LESS

Using Stylus plugins

Running Automated Tests

Introduction

Running Jasmine tests

Running QUnit tests

Running NodeUnit tests

Running Mocha client-side tests

Running Mocha server-side tests

Generating coverage reports for server-side code using Mocha and Blanket

Generating coverage reports for client-side code using Mocha and Blanket

Generating coverage reports for client-side code using QUnit and Istanbul

Deployment Preparations

Linting JavaScript code

Uglifying JavaScript Code

Setting up RequireJS

Deploying to the End User

Introduction

Deploying to Rackspace Cloud Files

Deploying to AWS S3

Deploying over FTP

Deploying over SFTP

Deploying to GitHub Pages

Invalidating an AWS CloudFront distribution

Running commands over SSH

Creating Custom Tasks

Introduction

Creating an alias task

Creating a basic task

Accessing project configuration

Checking for required configurations

Checking for the successful execution of other tasks

Running non-blocking code in a task

Failing a task

Using command-line parameters

Enqueuing tasks to run

Creating a multi-task

Using options in a task

Using files in a task

Authoring Plugins

Introduction

Finding plugins

Contributing to a plugin

Setting up a basic plugin project

Creating a plugin task

Writing tests for a plugin task

Adding documentation for a plugin

Publishing a plugin

Static Sites

Introduction

Setting up a basic site project

Adding a page to the site

Adding content to the site

Adding data to the site

Creating and using a site layout

Generating pages from a collection

Using a plugin

Index

Customer Reviews

5 star

4 star

3 star

2 star

1 star

Processing only changed files

When running a task that processes files in one way or another, you'll soon realize that you probably don't want it to process all the files each time it is performed. This is especially true when the amount of files the task has to process becomes quite large.

This is where the newer (0.7.0) plugin can help out by ensuring that only the files that have changed since the task's previous run are processed, each time it is called to run. It can be used with any plugin that makes use of the standard files configuration and becomes especially useful when using a watcher to rerun tasks each time a file change is detected.

Getting ready

In this example, we'll work with the basic project structure that we created in the Setting up Grunt on a project recipe of this chapter. Be sure to refer to it if you are not yet familiar with it's contents.

How to do it...

The following steps take us through making use of the newer plugin to check the code quality of only the JavaScript source files that have changed since the last run.

We'll start by installing the package containing the newer plugin and loading its tasks by following the instructions provided in the Installing a plugin recipe of this chapter.
For the purpose of our example, we'll also install the contrib-jshint plugin and load its tasks by following the instructions provided in the Installing a plugin recipe of this chapter.
With all the required plugins installed, we can now add sample configuration for the jshint task, which will perform a code quality check on all the JavaScript files in the src directory. This is done by adding the following to our configuration:
```
jshint: {
  sample: {
    src: 'src/**/*.js'
  }
}
```
Tip
Note that the jshint plugin requires you to specify the files that are to be targeted by the task in the src configuration directly inside the target. In other cases, it is usually recommended to specify your target files using the files configuration.
Now we can run the jshint task a couple of times using the grunt jshint command to observe its behavior. Each time we run it, we'll see that it scans all the files in the src directory. This should produce the same output each time, similar to the following:
```
Running "jshint:sample" (jshint) task
>> 3 files lint free.
```
In order to make use of the newer plugin, we prepend newer: to the name of the task we wish to run. On running the grunt newer:jshint command the first time, the newer plugin will cache the timestamps of the files that have been processed. This produces output similar to the following:
```
Running "newer:jshint" (newer) task

Running "newer:jshint:sample" (newer) task

Running "jshint:sample" (jshint) task
>> 3 files lint free.

Running "newer-postrun:jshint:sample:.cache" (newer-postrun) task
```
When we run the grunt newer:jshint command again, we'll see that no files are processed by the jshint task, which produces output similar to the following:
```
Running "newer:jshint" (newer) task

Running "newer:jshint:sample" (newer) task
No newer files to process.
```

Now, we can change one of the files in the src directory and run the command again to see that the changed file is processed again:

Running "newer:jshint" (newer) task

Running "newer:jshint:sample" (newer) task

Running "jshint:sample" (jshint) task
>> 1 file lint free.

Running "newer-postrun:jshint:sample:1:.cache" (newer-postrun) task

There's more...

Processing only changed files becomes especially useful when making use of the watch task provided by the contrib-watch plugin. A watch task will rerun its indicated tasks every time it observes a file change, which can happen quite often during development, and can take quite a bit of time if the tasks target a large number of files.

The following steps provide an example of how to use the newer plugin in conjunction with contrib-watch and continues with the work we did in the main recipe:

We'll start by installing the package that contains the contrib-watch plugin and loading its tasks by following the instructions provided in the Installing a plugin recipe of this chapter.
Now, we'll add a watch task, which will run the jshint task when it observes changes on any of the JavaScript files contained in the src directory. We'll also prepend the jshint task with newer: to indicate that we only want to process the files that actually changed. This is done by adding the following to our configuration:
```
watch: {
  jshint: {
    files: ['src/**/*.js'],
    tasks: ['newer:jshint']
  }
}
```
Now, we can start the watch task by using the grunt watch command in the terminal. This should produce output similar to the following, indicating that the watcher is running:
```
Running "watch" task
Waiting...
```

If we now change and save a file in the src directory, we should see output similar to the following, indicating that only the file that was changed has been processed by the jshint task:

>> File "src/file.js" changed.
Running "newer:jshint" (newer) task

Running "newer:jshint:sample" (newer) task

Running "jshint:sample" (jshint) task
>> 1 file lint free.

Running "newer-postrun:jshint:sample:1:.cache" (newer-postrun) task

Grunt Cookbook

By : Jurie-Jan Botha

Grunt Cookbook

By: Jurie-Jan Botha

Overview of this book

Related Content you might be interested in

Current Title:

Grunt Cookbook

Processing only changed files

Getting ready

How to do it...

Tip

There's more...