This situation is due to npm’s policy shift following the infamous “left-pad” incident in 2016, where a popular package left-pad was removed, grinding development to a halt across much of the developer world. In response, npm tightened its rules around unpublishing, specifically preventing the unpublishing of any package that is used by another package.
This already seems like a pretty strange approach, and takes away agency from package maintainers. What if you accidentally published something you want to remove…? It kind of turns npm into a very centralized system.
If they don’t want to allow hard-removals because of this, why not let people unpublish packages into a soft/hidden state instead? Maybe mark them with the current dependencies, but don’t allow new ones - or something
I prefer the approach of Azure DevOps more. When you publish any nuget, or npm into their system, the entire package dependency tree is pulled in and backed up there. So you don’t rely on NPM anymore to keep your referenced packages safe
I feel like you could also give the maintainers the power to “re-publish” using a different verified maintainer so that if such a thing does happen, it can be reversed without input from the maintainer that originally pulled it. I don’t know enough about the system to really know if this is a good idea tho.
Yeah then you’ve got security problems. If a maintainer pulls a package, you wouldn’t want some rando able to push a new one in its place.
I see this as a delightful and very apropos revenge against how they treated Azer Koçulu for his use of kik as a package name, and how they tore it out of his hands simply because he wasn’t some million-dollar corp with an army of vampire lawyers.
Any truly fair system would have a “you used it legitimately first, you can have it” system.
You want to centralize control, and kick small devs in the teeth? Enjoy the fallout, f**kers.
What I want to know is how big would me node_modules be if I’d managed to install this?
Fastest answer I could find was from 2021: 285GB.
So make sure you have over half a terrabyte of free storage before you try this. These libraries can do things on install, like download and compile binaries. Then there’s overhead for inodes and such, since we’re talking about millions of files. So the impact to the filesystem is going to be much, much bigger than any figure cited like the above.
Amazing, thank you!
yes
Any site that uses AI generated images for the thumbnail can fuck off, I’d rather see nothing
I know it’s fun to mock
npm, but it any package registry secure from something like this? Is there any public package registry that reviews all its packages?It’s less of an issue of reviewing all packages than it is that this causes DOS in the first place. It’s pretty damn stupid that you can’t unpublish packages others depend on, and the whole recursive dependencies thing makes the situation a lot worse than it otherwise would be. Neither of these are issues with other package registries.
One problem that’s particular to node is that you can’t unpublish packages if another package depends on them. As it says in the article, that means that no one can unpublish their packages, including the everyone package since someone apparently depends on that.
