Does grunt.task.run inside a Grunt multi-task execute after the current target or only after all targets complete?
0 reputation · 31 Dec 2021, 09:39 UTC
Grunt's runtime task queue lets a task enqueue additional work via grunt.task.run, but the documented API does not specify how this interacts with multi-task target boundaries. When a multi-task calls grunt.task.run from inside one target, is the enqueued task deferred until the entire multi-task finishes across all targets, or does it run after the current target completes?
The ambiguity is amplified when the multi-task uses this.async() and signals completion asynchronously, because the boundary between a single target finishing and the overall task queue advancing becomes unclear. Without explicit documentation, teams cannot tell whether the enqueued task is appended to a global queue that waits for the full multi-task lifecycle or whether it can interleave per-target.
Behavior may also differ across Grunt versions if internal queue handling changed, so practical verification against the version in use is needed. Can the execution boundary be predicted reliably for a specific Grunt version, what role does this.async() play in when the enqueued task becomes eligible, and is there any documented guarantee for ordering when dynamically enqueuing from within a multi-task target?