Don't Make NPM Packages Unless You Need To

We reached the 1 million packages mark in NPM - the de facto package manager in Node.js. And trust me about 30% or so of those are doing the same thing. So the question now stands - when is enough, enough?

Going back

Back in its early days, Node.js was rather a simple runtime that was limited by the lack of libraries, as time went on however, more and more people went on to make tools, libraries and even Cloud IDEs. Node.js started a revolution where JavaScript was no longer confined in the browser, and it was good at it.

But as time went on, Node.js became more robust and it started to be ahead of the curve of the browsers - it was the new JavaScript ecosystem, where its not constrained of the vendor's lackluster ECMAScript support. And some of the ancient libraries became more obsolete as time goes on.

But what does this have to do with NPM packages?

The thing is, during those early days, also came with package pollution (and its still an issue today) where there's more useless packages than something that has purpose. Some of them even reinventing the wheel only to be abandoned for almost 6 years in some packages.

In this example, we have different packages for Redis, which hasn't been maintained for quite a while now (however its still understandable for grunt packages to be unmaintained since they've been superseded already), and most of them is something you can do in a app-level implementation, which you clearly don't need a package is for.

So stop reinventing the wheel - unless you need to

Let's say you invented a logger, cool! You want people to use it, even cooler! But let me remind you there's always tons of libraries that does the same thing, so if your logger is domain-specific, don't even try making it a NPM package and just keep it inside the project you intend to use it.

There are only instances of when you need to really invent the wheel for everyone's benefit - because the current public library was underperforming or just plain bad.

Let's take a little practical example, two SauceNAO API wrappers, I'll let you be the judge.

• Exhibit A
• Exhibit B

(Spoiler: Exhibit B is objectively biased as it is my own project - but you can see the point I was trying to get across).

And stop making packages with no useful purpose at all

Seriously, stop. You're ruining the point of a package repository, which is a repository for reusable modules to be used by a project. I don't care if its a joke package, you're wasting object storage where it could've been taken by a more useful module.

We have sane package repositories like Maven and PackageCloud, so why can't we have the same professionalism and sanity as they do? We're not so different from them at all.

Conclusion

NPM and the JavaScript community is the driving force of what we are now calling the "modern web". But if we keep doing useless stuff and keep misunderstanding the concept of having package managers in a runtime, then we can become an example of what a package manager shouldn't be.

So let's try to change the mindset with library authoring - only make something when there's no other way or when the current implementation is very underwhelming for a vast demographic. If you're making something for a domain-specific project, just don't bother at all.