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.
(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.
Top comments (10)
I'm not sure I understood what the consequences are of polluting npm.
Yes it would be better if NPM was cleaner but the fact uploading a package has such low knowledge threshold compared to other languages allows way more people to upload packages, especially beginners and I don't necessarily see a problem with that if they learn something in the process.
My point is all the incentives to upload a package are there and the downsides aren't significant so people have no reason to stop publishing "trash" packages.
P.S.
A few "funny" packages really improved my mood when I stumbled upon them. I think that's also valuable.
I agree with the low treshold making people create more, but I just keep noticing NPM pollution, spare the joke packages. It's just not funny to see things like
is-a-number,is-a-xy.How useful is this npmjs.com/package/shoutcloud
ALL CAPS AS A SERVICE
I cannot agree. People like reinventing the wheel. For learning or just for fun. When they do - why not share it? Just because a package lands in GitHub and npm it doesn't mean general public has to use it. If it's shit just don't. If people do use it, it was useful. Who are we to judge and to be a quality gatekeeping arbiter?
There is a right to complain when you start seeing packages that already exists in JavaScript natively. My standpoint here is that its okay to publish packages, but as long it helps people in a way. The main argument of the problem is that some of the packages is already existing as a builtin method/function. TC39 exists to improve some language intricacies, and maybe we should support more the upstream work instead of making our own solution.
As for some packages with no actual purpose, save the joke packages, is that some of them are literal empty packages (aka no dist files at all), hence why this has been a recurring problem in NPM.
That is mainly NPM's problem of not forcing namespacing in form of
username/package_name. Namesquatting wouldn't be a problem. Those "stupid" libraries - well, nobody forces anyone to use them, they are oftentimes polyfills that were required in the past and are obsolete now. It's up to project owners to update their dependencies and remove legacy stuff. I don't see a problem really, maybe with the exception of namesquatting. Essentially, if you find library useless - don't use it. If at least one person found a use for it - it is not useless. No need for gatekeeping.I saw this posted on the dev.to twitter and wrote a rebuttal:
dev.to/jfhbrook/make-npm-packages-...
I suspect you will disagree with my post, much as I disagreed with yours. You don't need to pay this any mind-rent if you don't want to - but I hope this is welcome.
You can, and you should, publish as org-scoped package, though; perhaps using your name.
Or, publish to GitHub registry, which is always your name scoped.
I think the same rules still applies, but it would be understandable to use GitHub registry for personal packages intended for a specific project, org scopes works as well but its not enough to actually solve the problem of redundancy.
I don't really agree with this at all. If someone writes open source software and wants to put it on npm they should. Dont worry about how popular it will be or if it is used at all. If you have an idea publish it. If later you find something better use that instead. The same could be said for dev.to. If you have something to say post it. Don't spend time worrying about what other people think. Just post it.
Java has 17 million package according to mvnrepository.com and I think that is a good thing.