Feb 29, 2024

Why Does 'is-number' Package Have 59M Weekly Downloads?

Why does this simple one-line package have so many downloads? Is the JS community filled with folks who can’t do this simple task without relying on a library? Are they rightfully the butt of all jokes? Have they learned nothing from the left-pad fiasco that broke the internet?

The answer is more nuanced than that. ‘npm’ methodology of counting downloads is admittedly naive.

npm’s download stats are naïve by design: they are simply a count of the number of HTTP 200 responses we served that were tarball files, i.e. packages. This means the number includes:

  • automated build servers

  • downloads by mirrors

  • robots that download every package for analysis

This has led to some programmers pumping up their download numbers by creating simple packages, and using them in their own packages, and using those packages to create more packages. As a result, these silly utility packages hide beneath multiple layers. Any successful package in the upper layers creates a cascade of increasing download numbers.

I don’t believe many programmers are using is-number knowingly. It just gets included when you use a popular package. In fact, it’s there even in my node_modules folder. I figured out the chain that led to its inclusion:

tailwindcss -> chokidar -> braces -> fill-range -> to-regex-range -> is-number

The last four packages in the chain have been written by the same author.


Nonetheless, this kind of dependency hell is ridiculous and something should be done about it. Too many packages are getting downloaded, consuming disk space and download time, that should ideally only be a single function or a part of a bigger lodash-like package. There are thirty-seven “is-*” packages in my node_modules folder. That’s just bonkers!

There are three solutions I can think of:

  1. npm should differentiate between direct and indirect downloads. I am not certain if it’s possible with how npm works, but downloads triggered by a dependency don’t accurately reflect the popularity of the package. People who visit the npm page are usually unaware of how the numbers work.

  2. There should be a concentrated effort to replace the packages causing this mess with packages that inline their dependencies.

  3. Like Bundlephobia, there should be a website that lists the total number of packages you’ll end up downloading when you include the dependency. Hopefully, it will encourage the community to seek packages with fewer indirect dependencies.

Tons of hidden costs come with having hundreds of dependencies, but the JS community has largely ignored them. It’s time we made some effort to address the issue.


Follow Me!

I write about things that I find interesting. If you're modestly geeky, chances are you'll find them too.

Subscribe to this blog via RSS Feed.

Don't have an RSS reader? Use Blogtrottr to get an email notification when I publish a new post.