Best way to handle large grunt files

I love Grunt. Each project I’ve done last year I’ve used it to automate linting, building, testing, etc. There’s just one thing which keeps on bothering me: once a project grows, so does the grunt file. I just keep on finding new grunt plugins and adding them to my projects. With every plugin, task configuration and declarations are added to the Grunt file and its size just keeps on growing, making it very messy and hard to maintain IMO.

TL;WR (too long;won’t read)

We’re having a discussion on the best way to manage large grunt files in this thread of the yeoman generator-webapp project. Let us know what you think!

So, what’s it all about?

To me, the best way to manage grunt task configurations is by splitting it all up into several files.

I wrote a module load-grunt-configs which loads your grunt task configuration objects from files in a directory.

(Disclaimer: Initially it was based on this excellent article from Thomas Boyt whom was apparently taking a similar approach, but along the way it evolved on its own.)

Usage is simple, you extract from the Gruntfile.js all configuration objects like this:

    jshint : {
        options : {
            jshintrc : '.jshintrc'
        app : [
            '<%= app %>/scripts/{,*/}*.js'

And move them to their own file in a config directory.
(In the example: config/jshint.js).

This gives you something along the lines of:


— EDIT: 18/02/14
I wrote another module which automatically extracts the grunt configuration from your Gruntfile and generates the separate files for you: grunt-generate-configs. See the project for full details.

Next, you use the load-grunt-configs module to load all the configuration objects from the config directory at once.

    // Load grunt configurations automatically
    var configs = require('load-grunt-configs')(grunt);

    // Define the configuration for all the tasks

See this demo for a full example.

Two other split-configuration approaches

Just so you know, there are 2 other approaches when it comes to splitting your grunt file configuration. (If you have a slightly or radically different approach let us know so!)

Most people will be familiar with the first one, but I think the second will be new to them:

  1. A single configs file. The entirety of the grunt configuration is moved to a seperate file (grunt.js). This way the Gruntfile.js only contains task declarations.
  2. Configuration by task type. Task target configurations are spread over multiple files and grouped wherever logically it makes sense.
    E.g. build.js, serve.js, test.js

Harassing other, far smarter people

I use yeoman to scaffold my projects and had noticed their generators never use the split-configuration-file approach. So I started prodding the yeoman team about adding this approach to their webapp generator, but in their experience it’s harder to share configuration across multiple task files compared to a single gruntfile in regards of maintenance and collaboration.

So we decided to poll the community what your experiences are, and what you’d prefer.

What do you think, would it be best to split the grunt configuration into separate files or not?
And should the yeoman generator-webapp provide you out of the box with this?

Please let us know in this thread what you think.

  1. I think it’s a good idea to split the Grunt configuration into several files and therefore should be included in the generators. Cheers.

    • Andy
    • July 11th, 2014

    I use load-grunt-tasks and have managed to replicate the exact same (well, near enough) configuration using that as yeoman does with it’s all-in-one configuration file.

    One thing that put me off using Yeoman was the complexity of Grunt.js. I wanted to go in there and mess around with it a bit so I could learn some more, but the whole thing was just so unwieldy and messy, that became a problem.

    When I started to use load-grunt-tasks, that problem went away, and my appreciation of Grunt grew as a result.

    • @Andy Yeah I feel your pain, I’ve spent many hours trying to decode the yeoman generated grunt configuration as well. In the mean time I do think I know how it all fits together, should you have any questions, let me know!

      And … surely you meant you use load-grunt-configs? Since the yeoman generated grunt file uses load-grunt-tasks as well.

  2. Why not have both options? The team choose the best for them.

    • Ummm… I’m not sure what both options you’re talking about? Do you mean it would be best to have the options to generate a single config file or multiple in yeoman?
      I campaigned for it, but the yeoman team didn’t think it useful and perhaps a bit too confusing for new yeoman users. I don’t agree, but there’s not much I can do.

  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: