Mastering JavaScript Single Page Application Development

You will notice that the version number of the installed package is preceded by a caret (^) symbol by default. This means that package updates will only allow patch and minor updates for versions above 1.0.0. This is meant to prevent major version changes from breaking your dependency chain when updating your packages to the latest versions.

To update your devDependencies and save the new version numbers, you can enter the following from the command line:

$ npm update --save-dev

Alternatively, you can use the -D option as a shortcut for --save-dev:

$ npm update -D

To update all globally installed NPM packages to their latest versions, run npm update with the -g option:

$ npm update -g

For more information on semantic versioning within NPM, see docs.npmjs.com/misc/semver.

Now that you have NPM set up and you know how to install your development dependencies, you can move on to installing Bower.

Most Grunt tasks expect their configuration to be defined within a property of the same name as the task, which is the suffix of the package name. For example, jshint is the Grunt task name for the grunt-contrib-jshint package we previously installed:

module.exports = function(grunt) { 
    'use strict'; 
    grunt.initConfig({ 
        pkg: grunt.file.readJSON('package.json'), 
        jshint: { 
            options: { 
                curly: true, 
                eqeqeq: true, 
                eqnull: true, 
                browser: true, 
                newcap: false, 
                es3: true, 
                forin: true, 
                indent: 4, 
                unused: 'vars', 
                strict: true, 
                trailing: true, 
                quotmark: 'single', 
                latedef: true, 
                globals: { 
                    jQuery: true 
                } 
            }, 
            files: { 
                src: ['Gruntfile.js', 'js/src/*.js'] 
            } 
        } 
    }); 
}; 

Here you can see that the jshint property of the configuration object is defined and is assigned its own properties which apply to the jshint Grunt task itself. The options property defined within jshint holds the settings you wish to validate against when linting your JavaScript files. The files property defines a list of the files you wish to validate. For more information on the supported options for JSHint and what they mean, see jshint.com/docs/.

Let's now add an additional configuration for the grunt-contrib-watch plugin watch task below the jshint task configuration:

watch: { 
    jshint: { 
        files: ['js/src/*.js'], 
        tasks: ['jshint'] 
    } 
} 

Here we add an additional namespace of jshint underneath the watch task, which allows for other targets to be defined within the same configuration property and run separately if needs be. This is what is known as a multitask. Targets within a multitask can be named arbitrarily and will simply be run in the order which they are defined if the multitask is called alone. A target can be called directly as well, and doing so will ignore any of the other targets defined within the multitask's configuration:

$ grunt watch:jshint

This particular configuration for the target jshint tells the watch task that if any files matching js/src/*.js are changed, then to run the jshint task.

Now you have your first two Grunt task configurations defined within your Gruntfile, but in order to use them, we must load the Grunt tasks themselves.

You have already installed the grunt-contrib-jshint plugin as a Node.js module, but in order to execute the jshint task, you must load the plugin within your Gruntfile. This is done after the grunt.initConfig call:

grunt.loadNpmTasks('grunt-contrib-jshint'); 

This is the same method call you will use to load all Grunt tasks within your Gruntfile, and any Grunt task will not be accessible without doing so. Let's do the same for grunt-contrib-watch:

grunt.loadNpmTasks('grunt-contrib-watch'); 

Your full Gruntfile should now look like this:

module.exports = function(grunt) { 
    'use strict'; 
    grunt.initConfig({ 
        pkg: grunt.file.readJSON('package.json'), 
        jshint: { 
            options: { 
                curly: true, 
                eqeqeq: true, 
                eqnull: true, 
                browser: true, 
                newcap: false, 
                es3: true, 
                forin: true, 
                indent: 4, 
                unused: 'vars', 
                strict: true, 
                trailing: true, 
                quotmark: 'single', 
                latedef: true, 
                globals: { 
                    jQuery: true 
                } 
            }, 
            files: { 
                src: ['Gruntfile.js', 'js/src/*.js'] 
            } 
        }, 
        watch: { 
            jshint: { 
                files: ['js/src/*.js'], 
                tasks: ['jshint'] 
            } 
        } 
    }); 
    grunt.loadNpmTasks('grunt-contrib-jshint'); 
    grunt.loadNpmTasks('grunt-contrib-watch'); 
}; 

Now that you have the plugin loaded, you can simply run grunt jshint from the command line to execute the task with its defined configuration. You should see the following output:

$ grunt jshint
Running "jshint:files" (jshint) task
>> 1 file lint free.
Done, without errors

This will run your JSHint linting options against the defined files, which as of now consist of only Gruntfile.js. If it looks like the example file shown and includes the call to grunt.loadNpmTasks('grunt-contrib-jshint'), then it should pass without errors.

Now let's create a new JavaScript file and intentionally include some code which will not pass the JSHint configuration so we can see how the errors are reported. First, create the js/src directory, which is defined in the files property of the jshint task:

$ mkdir -p js/src

Then create a file named app.js within this directory and place the following code in it:

var test = function() { 
    console.log('test'); 
}; 

Now run grunt jshint again from the command line. You should see the following output:

$ grunt jshint
Running "jshint:files" (jshint) task
   js/src/app.js
      2 |    console.log('test');
             ^ Missing "use strict" statement.
      1 |var test = function() {
             ^ 'test' is defined but never used.
>> 2 errors in 2 files
Warning: Task "jshint:files" failed. Use --force to continue.
Aborted due to warnings.

You will notice that two errors are reported for js/src/app.js based on the jshint task configuration options. Let's fix the errors by changing the code in app.js to the following:

var test = function() { 
    'use strict'; 
    console.log('test'); 
}; 
test(); 
 

Now if you run grunt jshint from the command line again, it will report that the files are lint free and have no errors:

$ grunt jshint
Running "jshint:files" (jshint) task
>> 2 files lint free.
Done, without errors.

As mentioned earlier, when the watch task is run it will wait for changes that match the file patterns defined in its configuration and run any corresponding tasks. In this case, we configured it to run jshint when any files matching js/src/*.js are changed. Since we defined a target within the watch task called jshint, the watch task can be run in two different ways:

$ grunt watch

Running grunt watch will watch for changes matching all target configurations defined within the watch task:

$ grunt watch:jshint

Running grunt watch:jshint with the colon (:) syntax runs watch for just the file patterns matching that target configuration. In our case, only one target is defined, so let's just run grunt watch and see what happens in the console:

$ grunt watch
Running "watch" task
Waiting...

You will see that the task now shows a status of Waiting... on the command line. This indicates that the task is running to watch for matching changes within its configuration, and if any of those changes are made, it will automatically run the corresponding tasks. In our example with the jshint task, it will allow your code to automatically be linted every time you make changes to your JavaScript files and save them. If a JSHint error occurs, the console will alert you and display the error.

Let's test this by opening a text editor and changing js/src/app.js again:

var test = function() { 
    console.log('test'); 
}; 
test() 

Here, we removed the opening use strict statement and the semicolon after the call to test() at the end of the file. This should raise two JSHint errors:

>> File "js/src/app.js" changed.
Running "jshint:files" (jshint) task

   js/src/app.js
      2 |    console.log('test');
             ^ Missing "use strict" statement.
      4 |test()
               ^ Missing semicolon.
>> 2 errors in 2 files
Warning: Task "jshint:files" failed. Use --force to continue.
Aborted due to warnings.

Now let's correct these errors and return the file to the way it was before:

var test = function() { 
    'use strict'; 
    console.log('test'); 
}; 
test(); 

Press Ctrl + C from the command line at any time to abort the watch task, or any Grunt task, while it is running.

Grunt allows you to define a default task which will run when you simply type grunt on the command line with no parameters. To do this, you will use the grunt.registerTask() method:

grunt.registerTask('default', ['jshint', 'watch:jshint']);

This example sets the default Grunt task to run the defined jshint task first and then the watch:jshint multitask target. You can see that the tasks passed to the default task are in an array, so you can set the default task for Grunt to run any number of tasks by simply typing grunt on the command line:

$ grunt
Running "jshint:files" (jshint) task
>> 2 files lint free.
Running "watch:jshint" (watch) task
Waiting...

From looking at the output, you can see that the jshint task was run once initially, and then watch:jshint was run to wait for additional changes to the configured file patterns.

Grunt allows you to define your own custom tasks, in the same way that you defined the default task. In this way, you can actually write your own custom tasks directly within the Gruntfile, or you can load them from an external file, just as you did with grunt-contrib-jshint and grunt-contrib-watch.

Alias tasks

One way of defining a custom task is to simply call one or more existing tasks in the order you want them to be run:

grunt.registerTask('my-task', 'My custom task.', ['jshint']); 
 

In this example, we have simply defined a task named my-task to serve as a proxy for jshint. The second parameter is an optional description of the task, which must be a string. The third parameter, which passes an array, including only jshint in this example, must always be an array. You can also forgo the second parameter with the description and pass in your array of tasks there instead. This way of defining a task is known as an alias task.

Basic tasks

When you define custom Grunt tasks, you are not limited to only calling other tasks that exist within your configuration, but you can write JavaScript code to be called directly as a function. This is called a basic task:

grunt.registerTask('my-task', 'My custom task.', function() { 
    grunt.log.writeln('This is my custom task.'); 
}); 

In this example, we simply write a string to the command line output for the task. The output should look like this:

$ grunt my-task
Running "my-task" task
This is my custom task.

Let's expand upon this example and pass in some arguments to our basic task function, as well as access the arguments from within the function:

grunt.registerTask('my-task', 'My custom task.', function(arg1, arg2) { 
    grunt.log.writeln(this.name + ' output...'); 
    grunt.log.writeln('arg1: ' + arg1 + ', arg2: ' + arg2); 
}); 

You will notice that there is a property available to the basic task, this.name, which is simply a reference to the name of the task. In order to call a basic task from the command line and pass arguments in, you will use a colon after the task name to define each argument in succession. This syntax is just like the syntax for running a multitask target; however, in this case you are passing in arbitrary arguments:

$ grunt my-task:1:2

Running this will output the following:

Running "my-task:1:2" (my-task) task
my-task output...
arg1: 1, arg2: 2

If you do not pass in the arguments to a task that is expecting them, it will simply resolve them as undefined:

$ grunt my-task
Running "my-task" task
my-task output...
arg1: undefined, arg2: undefined
Done, without errors.

You can also call other tasks from within a custom task:

grunt.registerTask('foo', 'My custom task.', function() { 
    grunt.log.writeln('Now calling the jshint and watch tasks...'); 
    grunt.task.run('jshint', 'watch'); 
}); 

In this example, we have created a task, foo, that defines a custom function that calls the existing jshint and watch tasks:

$ grunt foo
Running "foo" task
Now calling the jshint and watch tasks...
Running "jshint:files" (jshint) task
>> 2 files lint free.
Running "watch" task
Waiting...

For more information on creating custom tasks with Grunt, see gruntjs.com/creating-tasks.

These examples of tasks only scratch the surface of what is capable with Grunt, but you should be able to glean from them the power of it and begin to think about what might be possible with Grunt tasks when building your own SPA.