This should not be a plugin. This should be a recipe documenting how task dependencies work.

[robrich]

You've basically copied parts from orchestrator's run method and parts from orchestrator's task method and cobbled them here. It just adds complexity. Just use task dependencies.

[OverZealous]

I agree that this is not a plugin, and plan on renaming it and changing it to gulp-friendly once I get some time. This was a recent discussion, and I there wasn't much information about how to provide gulp-related non-plugin code.

However, dependencies do not always solve problems with methods. It is very common to have methods that must occur after other methods, but are not dependent on those methods. The best example for this is running something like clean-then-compile. Compile doesn't depend on clean, however, if clean occurs after (or during) compile, it breaks everything.

Another example is complex compilations, such as compile js and css, then compile html. I want to be able run each of these independently, but I need to make sure that JS and CSS tasks have completed before I can process the HTML. I do not want to recompile the JS and CSS every time I change the HTML file, though, as that would be unnecessary.

There's no method within Orchestrator to set up something like "task must run after other task", so this was my solution. I didn't cobble it together, I actually wrote it to solve a failure of the tool.

[OverZealous]

I should clarify. I know that it's relatively easy to make one-off tasks that handle simple dependencies using the task dependencies. It's more a complex, non-linear dependency that's the issue, namely this one:

clean -> [compile-css, compile-js] -> compile-html

In this case, I need to clean, the when that's complete, run both compile-css and compile js, then when both of those complete, run compile-html. I don't see any way to solve this using traditional dependencies, because I've got a parallel execution path between compile-css and compile-js. You can't use the gulp.run() callback, because that's effectively a global method attached to Orchestrator, and it gets executed every time a series of tasks complete. (Also, it won't get called if we're inside a larger task chain!)

I realize that this code could be copied-and-pasted into a gulpfile, but it's useful enough, and solves a complex enough pattern that I think it will be useful.

I will leave this library out there, but not as a gulpplugin, of course!

Trust me, I get the gulp philosophy, but be careful just assuming that complex task dependencies are easily solved with a ordered graph. This bit the developer of Gradle, too, who fought hard against adding something else, but eventually added a task.mustRunAfter() method to solve these sorts of not-really-a-dependency issues.

[OverZealous]

I renamed project and removed gulpplugin from the keywords list. Deprecated old gulp-run-sequence and removed the keyword there, too.

[robrich]

Very well articulated. I like the "need to ensure they're done but don't redo them" idea. Let's build this into orchestrator in time.

[OverZealous]

Great! I look forward to it. runInOrder() is probably a better name for the method if it's on the object itself.