On Discoverability of JavaScript Packages

I really like the idea of extracting tiny tasks to separate libraries like David Clark suggests or like master of one-line modules Sindre Sorhus do.

But as user of these small libraries I always struggle with finding the right packages:

  1. npm has almost 250 000 packages and most of them are bad: no tests, no license, no docs, readme in Chinese, even no code sometimes.
  2. Many packages do the same thing and even have almost identical code.
  3. Many packages were abandoned: no updates, author doesn’t use them either.
  4. People still publish their packages on Bower only.
  5. Sometimes it’s hard to understand what to search: what the right thing to outsource is and what could possibly have been done before.

Juho Vepsäläinen has a list of npm search tools but they don’t solve the problem.

This is still an unsolved question for me and I hope we’ll see more sophisticated search tools that will consider many parameters to rank search results: npm installs in the last month, GitHub stars, latest release date, opened issues, test coverage, etc.

JS.coach is very close to that but they only have modules for React, Webpack, Babel, etc.

And I believe it will decrease the number of almost identical libraries because authors will be able to easily find what’s already available.

Update. Looks like the search problem is pretty much solved by the new npms.io. It’s really awesome!

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.