Javascript – Continue certain tasks in grunt even if one fails

grunt-contrib-qunitgruntjsjavascript

Is there a way to configure a sequence of tasks so that specific subsequent ones (I don't want –force on the whole batch) run even if one fails? For example, consider a case like this

Create some temporary files
Run some unit tests which involve those temporary files
Clean up those temporary files

I can do this:

grunt.registerTask('testTheTemp', ['makeTempFiles', 'qunit', 'removeTempFiles']);

But if qunit fails then the removeTempFiles task never runs.

Best Solution

Here's one workaround. It's not pretty, but it does solve the issue.

You create two extra tasks which you can wrap at the beginning/end of any sequence that you want to continue even over failure. The check for existing value of grunt.option('force') is so that you do not overwrite any --force passed from the command line.

grunt.registerTask('usetheforce_on',
 'force the force option on if needed', 
 function() {
  if ( !grunt.option( 'force' ) ) {
    grunt.config.set('usetheforce_set', true);
    grunt.option( 'force', true );
  }
});
grunt.registerTask('usetheforce_restore', 
  'turn force option off if we have previously set it', 
  function() {
  if ( grunt.config.get('usetheforce_set') ) {
    grunt.option( 'force', false );
  }
});
grunt.registerTask( 'myspecialsequence',  [
  'usetheforce_on', 
  'task_that_might_fail_and_we_do_not_care', 
  'another_task', 
  'usetheforce_restore', 
  'qunit', 
  'task_that_should_not_run_after_failed_unit_tests'
] );

I've also submitted a feature request for Grunt to support this natively.

The problem

You're using load-grunt-config to load a set of modules (objects that define tasks) and combine them into one module (object) and pass it along to Grunt. To better understand what load-grunt-config is doing, take a moment to read through the source (it's just three files). So, instead of writing:

// filename: Gruntfile.js
grunt.initConfig({
    foo: {
        a: {
            options: {},
        }
    },
    bar: {
        b: {
            options: {},
        }
    }
});

You can write this:

// filename: grunt/foo.js
module.exports = {
    a: {
        options: {},
    }
}

// filename: grunt/bar.js
module.exports = {
    b: {
        options: {},
    }
}

// filename: Gruntfile.js
require('load-grunt-config')(grunt);

Basically, this way you can split up a Grunt configuration into multiple files and have it be more "maintainable". But what you'll need to realize is that these two approaches are semantically equivalent. That is, you can expect them to behave the same way.

Thus, when you write the following*:

(* I've reduced the problem in an attempt to make this answer a bit more general and to reduce noise. I've excluded things like loading the tasks and extraneous option passing, but the error should still be the same. Also note that I've changed the values of the environment variables because the default was the same as what was being set.)

// filename: grunt/env.js
module.exports = {
    dev: {
        options: {
            add: {
                // These values are different for demo purposes
                NODE_ENV: 'dev',
                MONGO_PORT: 'dev_mongo_port',
                SERVER_PORT: 'dev_server_port'
            }
        }
    }
};

// filename: grunt/shell.js
module.exports = {
    mongod: {
        command: 'mongod --port ' + (process.env.MONGO_PORT || 27017)
    }
};

// filename: grunt/aliases.js
module.exports = {
    server: ['env:prod', 'shell:mongod']
};

// filename: Gruntfile.js
module.exports = function (grunt) {
    require('load-grunt-config')(grunt);
};

You can consider the above the same as below:

module.exports = function (grunt) {
    grunt.initConfig({
        env: {
            dev: {
                options: {
                    add: {
                        NODE_ENV: 'dev',
                        MONGO_PORT: 'dev_mongo_port',
                        SERVER_PORT: 'dev_server_port'
                    }
                }
            }
        },
        shell: {
            mongod: {
                command: 'mongod --port ' + (process.env.MONGO_PORT || 27017)
            }
        }
    });
    grunt.registerTask('server', ['env:dev', 'shell:mongod']);
};

Now do you see the problem? What command do you expect shell:mongod to run? The correct answer is:

mongod --port 27017

Where what you want to be executed is:

mongo --port dev_mongo_port

The problem is that when (process.env.MONGO_PORT || 27017) is evaluated the environment variables have not yet been set (i.e. before the env:dev task has been run).

A solution

Well let's look at a working Grunt configuration before splitting it across multiple files:

module.exports = function (grunt) {
    grunt.initConfig({
        env: {
            dev: {
                options: {
                    add: {
                        NODE_ENV: 'dev',
                        MONGO_PORT: 'dev_mongo_port',
                        SERVER_PORT: 'dev_server_port'
                    }
                }
            }
        },
        shell: {
            mongod: {
                command: 'mongod --port ${MONGO_PORT:-27017}'
            }
        }
    });
    grunt.registerTask('server', ['env:dev', 'shell:mongod']);
};

Now when you run shell:mongod, the command will contain ${MONGO_PORT:-27017} and Bash (or just sh) will look for the environment variable you would have set in the task before it (i.e. env:dev).

Okay, that's all well and good for the shell:mongod task, but what about the other tasks, Express for example?

You'll need to move away from environment variables (unless you want to set them up before invoking Grunt. Why? Take this Grunt configuration for example:

module.exports = function (grunt) {
    grunt.initConfig({
        env: {
            dev: {
                options: {
                    add: {
                        NODE_ENV: 'dev',
                        MONGO_PORT: 'dev_mongo_port',
                        SERVER_PORT: 'dev_server_port'
                    }
                }
            }
        },
        express: {
            options: {
                hostname: '127.0.0.1'
                port: (process.env.SERVER_PORT || 3000)
            },
            prod: {
                options: {
                    livereload: true
                    server: path.resolve(__dirname, '../backend/page.js'),
                    bases: 'dist/'
                }
            }
        }
    });
    grunt.registerTask('server', ['env:dev', 'express:prod']);
};

What port will the express:prod task configuration contain? 3000. What you need is for it to reference the value you've defined in the above task. How you do this is up to you. You could:

Separate the env configuration and reference its values

module.exports = function (grunt) {
    grunt.config('env', {
        dev: {
            options: {
                add: {
                    NODE_ENV: 'dev',
                    MONGO_PORT: 'dev_mongo_port',
                    SERVER_PORT: 'dev_server_port'
                }
            }
        }
    });
    grunt.config('express', {
        options: {
            hostname: '127.0.0.1'
            port: '<%= env.dev.options.add.SERVER_PORT %>'
        }
    });
    grunt.registerTask('server', ['env:dev', 'express:prod']);
};

But you'll notice that the semantics of the env task don't hold up here due to it no longer representing a task's configuration. You could use an object of your own design:

module.exports = function (grunt) {
    grunt.config('env', {
        dev: {
            NODE_ENV: 'dev',
            MONGO_PORT: 'dev_mongo_port',
            SERVER_PORT: 'dev_server_port'
        }
    });
    grunt.config('express', {
        options: {
            hostname: '127.0.0.1'
            port: '<%= env.dev.SERVER_PORT %>'
        }
    });
    grunt.registerTask('server', ['env:dev', 'express:prod']);
};

Pass grunt an argument to specify what config it should use
Have multiple configuration files (e.g. Gruntfile.js.dev and Gruntfile.js.prod) and rename them as needed
Read a development configuration file (e.g. grunt.file.readJSON('config.development.json')) if it exists and fall back to a production configuration file if it doesn't exist
Some better way not listed here

But all of the above should achieve the same end result.

Suddenly grunt build fails

Looks like you have outdated/mixed npm modules - did you merge your node_modules folder with your colleagues?

Anyway, I suggest deleting your local node_modules directory then re-running npm install.

Once you're stable again, the proper workflow should be:

node_modules should be out of source control
when you first get the project, run npm install to setup your local node_modules
then you only need to touch it when package.json changes
in that case, you run npm update to install the new versions locally

Best Solution

Related Solutions

Javascript – Grunt Environment Variables Don’t Get Set Until All Tasks Loaded

The problem

A solution

Suddenly grunt build fails

Related Question