DEV Community

Cover image for Don't Make NPM Packages Unless You Need To
Ayane Satomi
Ayane Satomi

Posted on

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.

Redis packages almost 6 years with no maintenance

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)

Collapse
 
strafer14 profile image
Michael Ostrovsky

I'm not sure I understood what the consequences are of polluting npm.

  • Is it storage space? I'm sure storage space is not a issue especially considering npm was just acquired by MS.
  • Is it that people consider the node eco-system a joke because all of this? Sure but people would always find a reason to look badly at a JavaScript based eco-system.

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.

Collapse
 
sr229 profile image
Ayane Satomi

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.

Collapse
 
wobsoriano profile image
Robert

How useful is this npmjs.com/package/shoutcloud

ALL CAPS AS A SERVICE

Collapse
 
galkowskit profile image
Tomasz Gałkowski

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?

Collapse
 
sr229 profile image
Ayane Satomi

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.

Collapse
 
galkowskit profile image
Tomasz Gałkowski

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.

Collapse
 
jfhbrook profile image
Josh Holbrook

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.

Collapse
 
patarapolw profile image
Pacharapol Withayasakpunt

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.

Collapse
 
sr229 profile image
Ayane Satomi

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.

Collapse
 
moaxcp profile image
John Mercier

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.