Fix callback argument order in async.auto

[aearly]

We should standardize the signature of async functions used in async.auto. Rather than always having the callback first, and the optional results object second, we should always make the callback the last argument.

We could also include a flip function that swaps the 2 arguments, to ease migration. (Or just instruct people to _.rearg(asyncFn, 1, 0)).

[ex1st]

Bad idea. For new ordering should be new function and "auto" stay like a flip wrapper for this (mark as deprecated).

[aearly]

One of the themes of the 2.0 release is standardizing the types of functions we use. This will be a well documented breaking change. I think breaking with node's async conventions originally was a worse idea.

[sgarbesi]

Touching on what @ex1st said.

@aearly Is it possible to make this a configuration preference?

async.auto.flipArgs = true/false ?

I literally probably have thousands of auto references and a countless number of callbacks depending on the ordering.

[aearly]

A config flag won't work well -- say all your functions expect the args flipped, but another node module expects the args un-flipped. If Async is de-duped to the same module, that config would conflict.

Wrapping all your dependent auto tasks with _.flip is probably the best way to migrate, until you can fix the callback ordering.

We didn't just arbitrarily make this change for the sake of standardization -- we made it so other higher-order functions would work properly. (e.g. directly passing the result of asyncify or timeout as an auto task function).

[Meekohi]

This was a bad idea imho :/ Now you can't just define a function(cb, r) and pass it to .auto regardless of whether or not it has a dependency. You have to check the number or type of arguments inside every function if you want it to be re-usable!

[sffc]

I think the consistency in 2.x is nice, but I agree that there are advantages to having the callback first. It's probably not worth changing at this point, but always having the callback first across the entire library, like the error argument, may have been a better design.