The npm registry provides a homepage for each package that it stores. Any JavaScript developer who has downloaded a package will know that the page shows teh download count for each package. I recently published a small package that I plan to use as a light-weight error-alerting middleware in a few side projects, and within the first few days I noticed it had 60 downloads. This is quite strange because I hadn’t told anyone about that pacakge and had downloaded it only twice myself.

Digging around, I found this blog which clearly states that their download counts are ‘naive’, as they are only calculated by the number or 200 HTTP responses for requests for that package. This includes CI pipelines downloading the package, npm mirrors downloading the package – which are an interesting topic of their own.

This makes sense, how else would they be able to determine what a ‘real’ download is? That is a highly subjective metric.

It would be dead simple to set up a script that automatically downloads the package over and over to artificially inflate the download count shown on the site. This is a problem though, because at least for myself, the download count can be a proxy for how popular and how reliable that package may be. Often when picking some open source tool, I weigh in the weekly download count as a proxy for usage, reliability, and how maintained the package is. Also, in reality there are packages that are downloaded by many that are not well maintained at all.

This isn't really a problem, though, because you should only treat the download count as a weak indicator for the aforementioned features. Looking at the number of github stars, how active their repo is, how many open Issues and PRs there are are all better indicators while it does take slightly more work to analyze those.