standardize methodology for long-living tasks

[dylang]

I've found it difficult in Grunt to construct tasks that need to stay alive and listen for events.

Example 1: grunt-contrib-livereload
Requires two tasks to work.

You are required to run livereload-start before all other tasks, and then livereload when you want the page to reload. Two tasks are required which is not typical, and the -start is an arbitrary label.

Example 2: grunt-contrib-uglify
Dies because it would be difficult to write to stay alive.

When one file changes grunt-contrib-uglify starts uglfiy from scratch reloading all files. Ideally it will be able to save the AST in memory and only reload the changed files. To handle this should there be another task called uglify-start?

Example 3: grunt-regarde (simular to grunt-watch)
By default it will die if it runs a tasks that throws an exception

This can be prevented if spawn: true is used, but then tasks have no knowledge of the changed files that caused them to run.

TLDR Basically I'm hoping for a recommendation or standard practice to handle these types of long-running tasks.

I'm sure I've used the wrong terminology for the title of this ticket. I'm happy to rephrase it.

[tkellen]

Sorry for the slow reply here Dylan. We are definitely going to address this--we're just working through the basic specification right now.

[dylang]

No worries, thanks for the response.

Are notes being collected publicly? I don't want to add confusion or suggestions that might be out of line of the goals and purpose of this project.