I think we all understand how much automating our simple and repetitive tasks can improve our efficiency and generally make our working day more enjoyable and Grunt is a great tool for doing this. But because it is so wonderful it can be so frustrating when when it breaks down. Today I ran into a particular hiccup with my Grunt tasks that caused this to happen and I thought I would share it here in hopes that it will help someone else to avoid the issue.

While beginning work on a fresh project I registered a simple ‘default’ Grunt task to run check the current state of my project with jshint, mocha-test and then start a watch task that would continue to check my work with jshint and mocha-test on any changes to my Javascript files. Simple right? It should have been but for some reason when it hit the watch task Grunt simply froze up, failing to start or run checks on any file changes. Here is what this looked like:

See the issue? I didn’t either, let me walk you through it. You see I had inherited this file and on line 33 it had a simple ‘watch’ task registered. I’ll admit I didn’t even pause to consider if this would cause a conflict. Looking back I can see how even if I had I might have reasoned that calling ‘watch’ in my ‘default’ task chain would just trigger the existing ‘watch’ task resulting in execution as normal. This is not, however, how this works.

When Grunt hits a task in the chain provided when registering a task it expects to look this task up in the object passed to the .config() call on line 3. When it instead finds a registered task it causes a conflict and is unable to execute. So, a simple removal of that old, and unnecessary, ‘watch’ task and everything runs exactly as expected!

A simple issue but I aim to avoid any interruption in the zen from automation and I hope this will help you do the same.