Also a check for Infinity (Infinity - Infinity -> NaN)

Which is weird since they use the isFinite built-in right after that, but I have no idea why they throw in all the string checks and trims and + for type coercion, and then use the global isFinite function which does all that internally. In fact the global function isFinite does everything this package does

(something I just learned tho checking this code out is that there is a global isNaN and isFinite which coerce strings into numbers automatically, and Number.isNaN and Number.isFinite which function similarly but without coercing the string first, so I guess this package exists as a learning aide of all the different ways to ask if something is a number)

EDIT: I now know why they check if a string input is not an empty string, because empty strings get coerced to 0, so isFinite("") returns true.

> EDIT: I now know why they check if a string input is not an empty string, because empty strings get coerced to 0, so isFinite("") returns true.

Yes, when coerced with +:

    Number.isFinite(+'') // true
    Number.isFinite('') // false

Number.isFinite('') and Number.isNaN('') returns false, isFinite('') and isNaN('') returns true, the global versions of isFinite and isNaN first coerce their input to number, no '+' necessary.

Hence the heading "Confusing Special Case Behavior" in the mdn docs: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

Oh yes the global versions.

Smart, but isNaN already exists…

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

It didn't at the time this library was created. I assume now that line only exists for backwards compatibility.

The MDN compatibility data says IsNaN was in node as of 0.10.0, which was released 2013-03-11. NPM says the library was first published 2014-09-21. And the library uses isFinite which was added in the same Node version. So... not really, no.

Anyway, my point wasn't so much that the code is an outrage, more that should anyone stumble across this comment thread they know that there is a much clearer and more obvious way to check for IsNaN than using x-x===0.

Sorry, I misunderstood which isNaN you were talking about. The global isNaN has unexpected behavior in certain edge cases[1], so that's probably why the library author chose to avoid it. Number.isNaN doesn't have that behavior, but is not supported in IE.

I agree most people these days should just use Number.isNaN, assuming they don't need to support IE.

[1]: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

this library uses the global isFinite, which actually you could just use instead of the whole function, since it does the string coercion and infinity check for you.

Check out the compatibility table on MDN, Chrome Firefox and Safari version 1 all support it, so I'm pretty sure isNaN and isFinite were in the original spec.

See the MDN section on "confusing special case behavior"[1] for why they probably didn't want to use the global version of isNaN. Number.isNaN handles those cases better but is not as widely supported.

[1]: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

Thanks for this, I had forgot that empty strings get coerced to 0... interesting choice.

I'd add that `num !== num` would be faster while `Number.isNaN(num)` would be faster and more readable.