[userbinator]

and because it updates fairly frequently

I fail to comprehend how a single-function-library called "isNumber" even needs updating, much less "fairly frequently".

The debate around third-party code vs. self-developed is eternal. IMHO if you think you can do better than existing solutions for your use-case, then self-developed is the obvious choice. If you don't, then use third-party. This of course says a lot about those who need to rely on trivial libraries.

[foul]

>I fail to comprehend how a single-function-library called "isNumber" even needs updating, much less "fairly frequently".

If someone uses isNumber as a fundamental building block and surrogate for Elm or Typescript (a transpiler intermediate that would treat number more soundly I hope), this poor soul whom I deeply pity will encounter a lot of strange edge-cases (like that one stated in the article: NaN is a number or not?) and if they fear the burden of forking the library they will try to inflict this burden upstream, enabling feature or conf bloat.

I insinuate that installation of isNumber is, like most of these basic microlibs, a symptom of incompetence in usage of the language. A worn JS dev would try isNaN(parseInt(num+'')) and sometime succeed.

[flysand7]

> [...] and sometime succeed

Nothing is ever certain when you program in javascript.

[guestbest]

I think the updates are more for bugfixes around edge cases than feature additions.

[consteval]

> I fail to comprehend how a single-function-library called "isNumber" even needs updating

Never underestimate the complexity and footgunny nature of JS' type system.