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.