grunt-sass and grunt-contrib-watch seems to not work together as expected

[adrienrn]

I use grunt-sass and grunt-watch to compile and minify my code

grunt.config('watch', {
    scripts: {
      files: ['<%= project.src.js.directory %>/*.js'],
      tasks: ['concat:scripts', 'uglify:compile']
    },
    styles: {
      files: [
        '<%= project.src.css.directory %>/**/*.scss'
      ],
      tasks: ['sass:compile', 'cssmin:minify']
    }
});

Problem:

When I modify one scss file, the sass:compile kicks in, grunt-contrib-watch detects changes on all javascript files and never run the cssmin:minify.

I thought grunt-contrib-watch was the cause (using spawn to false like instructed in https://github.com/gruntjs/grunt-contrib-watch/pull/509 kind of fix the issue).

However switching for grunt-sass to grunt-contrib-sass fixes the issue.

Does anyone have encountered the same issue?

---

For information, my package.json looks like this:

{
  ...
  "devDependencies": {
    "grunt": "~0.4.5",
    "time-grunt": "~1.3.0",
    "load-grunt-tasks": "~3.5.0",
    "grunt-contrib-concat": "~0.5.1",
    "grunt-contrib-uglify": "~0.9.2",
    "grunt-contrib-watch": "~0.6.1",
    "grunt-sass": "~1.1.0",
    "grunt-contrib-cssmin": "~1.0.1"
  }
}

[mikermcneil]

@adrienrn We're seeing this too (... I think.) But with LESS . And only sometimes.

[brandonheyer]

Slightly related, for the life of me I could not get grunt-sass-contrib to play nicely with watch after upgrading grunt. From my debugging it looks like a similar issue to what you were experiencing:

• taskrunner.js:run() get's called for scss change
• grunt-contrib-sass get's called
• .on('watch') for .css file is triggered
• taskrunner.js:run() get's called for css change (at this point sass task is still running, so method essentially returns as noop)
• grunt-contrib-sass finishes up
• no livereload trigger made, no tasks run for .css. While queued it was never told to run

I was able to get something sort of running by having all watch tasks interrupt eachother and have livereload at the top level. But this caused a double trigger on the css change and livereload, and seemed awfully sloppy.

No other combination of spawn: false or interrupt: true seemed to work. I used the same well documented config setup:

watch: {
  sass: {
    files: [**/*.scss],
    tasks: ['sass']
  },

  css: {
    files: [**/*.css],
    tasks: [],
    livereload: true
  }
}

With this setup the on watch event is not triggered until the sass task completes, thus there is no "running" watch task and the livereload is able to occur. To be honest I don't see much of a way around this, it seems like the queue / runner is treating additional taskrun's as all being the same, whereas I think that only subsequent taskrun's from the same target should not be ran (unless interrupt is set to true).

It seems like either the subsequent taskrunner.js:run() calls fired from watches should maintain separate queues per target, OR taskrunner.js:complete() should properly execute the remaining queue instead of just ignoring one's that have not started. From what I can see the queue only comes into play if you save several files under the 250ms mark, otherwise it is simply FIFO that only handles the head and never anything else.

My final working versions:

"grunt": "^1.0.1",
"grunt-sass": "^1.2.1",
"grunt-contrib-watch": "^1.0.0"

[elron]

Same here... solution?

[HerlikFal]

December of 2020 and I'm having a very similar issue. I have looked everywhere, did somebody came with a solution?

[EmmanuelBeziat]

December of 2020 and I'm having a very similar issue. I have looked everywhere, did somebody came with a solution?

February of 2022 now, still same issue.