Use arrays in input where that makes sense

[binki]

The whole steps: {step1: …, step2: …, …} thing seems like it should just be an array. The tasks thing too. That would make this library much easier to use, especially if I am supplying a set of tasks from a dynamic source.

[jimdebeer]

also nice with some functional things , map, reduce etc

[mstdokumaci]

named steps help with collecting results of each step.

line below will log result of step2 for task1:

console.log(runner.get(['tasks', 'task1', 'step2']).compute())

[binki]

In my case it makes doing simple things harder. Depending on the scenario, I’ve ended up instead using gulp-lock (makes it very easy to limit concurrency in a scope-oriented way—you can easily throttle Promise execution, not in any way dependent on gulp) and generic-pool (for shared expensive-to-initialize long-lived resources). No need to write a big plain object just to throttle concurrency (which is why I was looking into this project in the first place).

But my main argument is that it seems weird that object keys would be used for ordering steps. Dictionary/map objects aren’t always considered to have an ordering to them, even though they might in JSON and modern JavaScript engines. If you want to imply order, you must use arrays/sequences.

Based on the README, it looks like maybe this package searches for step1 and then for step2 and if it doesn’t find step2 assumes it’s done, which would not catch if you had a typo where you misspelled step2. With an array, that wouldn’t be an issue.

[mstdokumaci]

You're right about the order. Converting them to arrays now.

[mstdokumaci]

It's now accepting arrays, with a nicer API. Please use ^4.0.0