You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This is an expanded version of issue #33. That issue was closed, but the problem still exists since the commit that fixed it got reverted. I have some more details that should be helpful.
Start with this Gruntfile.js (slightly modified from the one is issue 33):
Create a file called shorttask in the same directory. Now, run grunt watch, then touch Gruntfile.js. Then, while 'longtask' is still running, run touch Gruntfile.js again. You'll notice that 'longtask' does not run again after it finishes. This was the original problem reported in issue 33.
However, you'll notice if you change the last step in the paragraph above to touch shorttask, then 'shorttask' will run after 'longtask' finishes. So, the problem above only applies to modifying files from the same watch group as the task that is running. I believe this is due to this line in watch.js.
But wait, there's more. If you repeat that, but first add options: {nospawn: true} to the watch config, then 'shorttask' will not run after 'longtask' finishes. When nospawn is set, the problem applies regardless of which watch group is modified.
To summarize:
Regardless of nospawn, modifications to a file from a watch group whose tasks are currently running get ignored.
When nospawn is true, modifications to a file from any watch group get ignored when any watch group's tasks are running.
The text was updated successfully, but these errors were encountered:
The behavior with spawn: true or the default is desired. Otherwise rapid file changes, especially with chained watched/triggered groups will cause infinite loops. #33 and d01491b isn't an adequate solution for this feature.
With spawn: false, unfortunately that is the limitations of how Grunt runs tasks, in a series. The watch task must stop before it can run other tasks. I'm looking into a solution for that within the current infrastructure but ideally we should break out and enhanced the Grunt task runner into it's own library to support this behavior. I've opened #258 for this but I'm more focused on breaking out the task runner as that will eventually solve more outstanding issues.
Happy to accept a PR with tests for this behavior if anyone has a better solution for this within the current infrastructure. Thanks!
For spawn: true: I understand that the specific implementation for #33 caused infinite loops, but there certainly exists some way to fix it without doing that. I think ignoring changes should never be the desired behavior.
For spawn: false, #258 may be related, but I'm pretty sure that's not the direct cause here.
This is an expanded version of issue #33. That issue was closed, but the problem still exists since the commit that fixed it got reverted. I have some more details that should be helpful.
Start with this Gruntfile.js (slightly modified from the one is issue 33):
Create a file called
shorttask
in the same directory. Now, rungrunt watch
, thentouch Gruntfile.js
. Then, while 'longtask' is still running, runtouch Gruntfile.js
again. You'll notice that 'longtask' does not run again after it finishes. This was the original problem reported in issue 33.However, you'll notice if you change the last step in the paragraph above to
touch shorttask
, then 'shorttask' will run after 'longtask' finishes. So, the problem above only applies to modifying files from the same watch group as the task that is running. I believe this is due to this line in watch.js.But wait, there's more. If you repeat that, but first add
options: {nospawn: true}
to the watch config, then 'shorttask' will not run after 'longtask' finishes. Whennospawn
is set, the problem applies regardless of which watch group is modified.To summarize:
nospawn
, modifications to a file from a watch group whose tasks are currently running get ignored.nospawn
is true, modifications to a file from any watch group get ignored when any watch group's tasks are running.The text was updated successfully, but these errors were encountered: