Watch doesn't detect cascading changes when nospawn is true

[bchabrier]

I have noticed a wrong behaviour of watch when nospawn is true. At least, watch doesn't behave the same as when nospawn is false.

The use case I am considering is a frequent use case where a change to a source file triggers a change to a destination file. This is typically the case when files are compiled (e.g. .sass files into .css), or copied to a production folder.

For the sake of simplification, I have built the following example:

copy: {
  cascade: {
    src: 'lib/source.js',
    dest: 'lib/destination.js',
  },
},

watch is configured to trigger the copy when the source file is modified. It also watches the destination file. Note the nospawn: true option:

watch: {
    cascading: {
      files: ['lib/source.js'],
      tasks: ['copy:cascade'],
      options: {
        nospawn: true,
      },
    },
    cascaded: {
      files: ['lib/destination.js'],
    },
},

With this configuration, a change of the source file should trigger the copy task, which modifies the destination file. This change is unfortunately not detected by watch, as shown by the traces:

$ grunt watch
Running "watch" task
Waiting...
>> File "lib/source.js" changed.
Running "copy:cascade" (copy) task
Copied 1 file

Running "watch" task
Completed in 0.098s at Mon May 30 2016 20:19:16 GMT+0200 (CEST) - Waiting...

On the other hand, when specifying nospawn: false, the modification of the destination file is correctly detected:

$ grunt watch
Running "watch" task
Waiting...
>> File "lib/source.js" changed.
Running "copy:cascade" (copy) task
Copied 1 file

Done, without errors.
Completed in 5.142s at Mon May 30 2016 20:22:15 GMT+0200 (CEST) - Waiting...
>> File "lib/destination.js" changed.
Completed in 0.001s at Mon May 30 2016 20:22:15 GMT+0200 (CEST) - Waiting...

Although using nospawn: false is a good workaround, it has much lower performances, hence it would be great if the issue could be fixed.

[xgiovio]

any news here?