Allow undefined in the first position of callbacks

[delaguilaluis]

Fixes #21.

[xjamundx]

I'm 👍 on this

[feross]

I actually prefer undefined to represent the un-set, default value for "nothing". And null to represent an explicit, user-set value for "nothing".

Pretty sure we intentionally excluded undefined when making this rule.

What's the reasoning for allowing undefined?

[delaguilaluis]

Interesting way to see it. Thank you.

Lately I tried to stick with only one way to represent the absence of value (undefined), so I bumped with this rule, and, after looking at the README, the rule description deferred from the behaviour:

• no-callback-literal - Ensures that we strictly follow the callback pattern with undefined, null or an error object in the first position of a callback.

That's the only reason for the change, and if this is a breaking change we don't want to ship, then maybe we should revert it and just update the README instead.

[feross]

@delaguilaluis Thanks for pointing out the inconsistency with the documentation. I'm curious what @xjamundx's opinion is on this stylistic issue. Let's wait to hear from him before publishing a new version or reverting.

[xjamundx]

Yeah hey I'm pretty out of touch on this stuff, but here's my 2 cents:

1. The callback pattern has historically been callback(null, data)
2. Since ES6 (especially with optional arguments) there has been a trend to use undefined as the one true empty value in JS

I don't see any special value in using undefined for the callback pattern, however, supporting this for folks that want to use undefined everywhere seems fine to me. 👍

[feross]

Fair enough :)

[feross]

Released as 3.1.0 ✨