Error: Invalid task name – grunt-contrib-watch spawn default change

The short answer

Starting with grunt-contrib-watch 0.5.x, the spawn option defaults to false instead of true. That means watch-triggered tasks now run inside the long-lived watch process rather than in a fresh child process. For most projects this is a performance win, but when one watch target's tasks write files that another target watches, tasks can interleave inside a single process — and the intermittent Invalid task name failures you describe are a classic symptom of that interleaving. The reliable fix for this case is to set spawn: true explicitly on the affected targets; no global upgrade is required.

1. Detecting which spawn behavior you have

First confirm the installed plugin version, since the default changed between 0.4.x and 0.5.x:

npm list grunt-contrib-watch

If the version is 0.5.x or later and your Gruntfile does not set spawn, you are running with spawn: false. Two runtime checks confirm it:

• Run Grunt with verbose output (grunt watch --verbose). With spawn: false, triggered tasks log in the same process and you will not see a new child process being launched per change.
• Check the process tree while a watch task runs (e.g., ps -ef | grep grunt). Spawned runs show a separate node process per task invocation; non-spawned runs do not.

Also grep your Gruntfile for spawn — a config inherited from an older project may already override the default in either direction.

2. Coordinating targets that touch shared files

Regardless of the spawn setting, having two watch targets where one's output is the other's input is fragile. The documented, well-established mitigations are:

1. Set spawn: true per target. Each triggered task runs in an isolated child Grunt process with its own task registry, so a half-finished run in the parent cannot corrupt task registration — the mechanism behind the Invalid task name error.
2. Exclude generated files from watch globs. If target A compiles src/ into build/, make sure target B watches src/ only, not build/. This removes the feedback loop entirely and is preferable to relying on process isolation.
3. Chain tasks explicitly instead of via watch. If B must always follow A, register a single task (grunt.registerTask('pipeline', ['compile', 'postprocess'])) and have one target run it, rather than two targets triggering each other through the file system.
4. Debounce with debounceDelay. Raising it (e.g., 500–1000 ms) reduces spurious double-triggers from editors that write files in multiple steps, though it does not fix true ordering races.

3. Minimal configuration fix

The scoped change that resolves the reported error without upgrading anything:

watch: {
  options: {
    spawn: true,        // restore 0.4.x isolation
    debounceDelay: 500
  },
  scripts: {
    files: ['src/**/*.js'],
    tasks: ['compile']
  }
}

Apply spawn: true only to the targets involved in the shared-file interaction if you want to keep the faster non-spawned behavior elsewhere.

Verification and caveats

After the change, edit a source file repeatedly and confirm (a) no Invalid task name errors appear and (b) --verbose output shows spawned child runs. Because the original failure is timing-dependent, a single clean run is not proof — exercise the exact edit sequence that previously failed, several times.

One caveat worth flagging for review: the exact version at which the default flipped, and edge cases around reload and interrupt options interacting with spawn, vary across the 0.5.x/0.6.x line. Confirm against the README shipped in your installed node_modules/grunt-contrib-watch rather than older online docs, which may still describe the 0.4.x default. If the error persists with spawn: true, the useful next diagnostic is the full stack trace — it would indicate a task-registration problem in the Gruntfile itself rather than a watch race.