Submitted 10 months ago by testeronious@lemmy.world to programming@programming.dev
https://socket.dev/blog/when-everything-becomes-too-much
We've since realized there is an issue with "star" versions - a.k.a depending on any/all versions of another package ( "package-xyz": "*" ) - any version of that package is now unable to unpublish.
kinda reminds me of the 'reply all' snafu that microsoft caused themselves, the complete system failures, and the subsequent attempts at controlling that feature
This is hilarious, but now I’m wondering, what would a saner package manger look like?
I’d say pip is saner, though not by much as its support for private registries is very bad and seems designed to facilitate supply-chain attacks. I’ve heard a lot of good things about cargo but haven’t used it enough myself to have a strong opinion.
The lack of a standard library is really the worst offender. Most of a given package directory is filled with middleware to handle JS’s lack of everything.
Pip is definitely not saner. The way installs are centralized has bitten me in the ass multiple times, when I wanted to have two different versions of Conan installed on a single machine.
And I know there are workarounds like virtualenvs, but they’re complex hacks. Stockholm syndrome yadda yadda yadda.
If it was sane, downloads would be centralized (no point in downloading the same package over and over again) but installs would be project-local (symlinks? There are multiple ways to do this, cf Conan)
Sure, NPM is wasteful with storage space but I’ll take inefficient over brittle any day.
The standard library thing is a really valid point, but how do you avoid recursive dependencies? Do you just not allow library packages to depend on anything?
pipis saner
Is it? It is very bare bones in my experience, I could never bring myself to use it until they make it a more fully fledged tool, such as the cargo you mentioned, yes
IDK any full-time JS or Node developers but they seem like they’re lazy and all have ADD. Packages developed for years still on version 0.x, packages depending on deprecated packages that were replaced by core functionality, packages still using CommonJS format (which I actually like better unfortunately), and popular packages without an update for 3 years. It feels like the entire ecosystem is for hobbyists only and businesses are like, “Cute language, but not for us.”
Ryan Dhal, the creator of node, litterally saw the npm problem(s) before incidents like this happened, and created Deno to fix his mistakes. And fix them he did because the Deno import system is incredible, and is effectly the only reason I use deno. You can just straight up import URLs, and deno vendors (aka caches) them. Deno has an equivlent to npm.org (Deno.land/x) but anyone can import straight from github, or make their npm.org equivlent, or import from their own private server. So if a company wants reliability, they can mirror deno.land while also avoiding unpublishing.
Yes, that’s really nice! Even though I haven’t touched it in a long time, I remember messing around with it out as soon as it came out a few years ago. There’s also nest.land between the alternative repositories, I find their concept interesting
have a look at nix
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
Cargo.rs also has no option to unpublish a package. There is however the option to yank a package which disables the inclusion in new projects by the automated dependency resolution. If the version is entered manually it will still be used.
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.
Any site that uses AI generated images for the thumbnail can fuck off, I’d rather see nothing
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.
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.
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.
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.
stackoverflow.com/…/is-it-possible-to-find-out-th…
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
key@lemmy.keychat.org 10 months ago
Node packaging is fucked. Node packaging remains fucked. And we have fucked it. How shall we comfort ourselves, the makers of all unmaintainable spaghetti? What was webscale and most utilitarian of all that the computers have yet executed has ground to a halt under our keyboards: who will wipe this blood off us?
FrameXX@discuss.tchncs.de 10 months ago
I am sorry, but as a noobie user of npm I don’t understand. It works pretty well for me if you use it normally for what it is supposed for.
dependencyinjection@discuss.tchncs.de 10 months ago
If used in larger systems it can be a pain to maintain code bases as you could install an innocuous package but that package may depend on 100 other packages which in turn could have other dependencies and it cascades.
This can introduce bugs into your code which can be a pain to resolve.
UnculturedSwine@lemmy.world 10 months ago
I’m curious if you mean this one issue talked about in the article is the only reason why node packaging is “fucked” or do you have any citations you can provide that point out other issues with it?
I feel this is just a natural progression of how the developers wanted it to function and this is an opportunity to resolve it.
Better that this is done by mistake and resolved than it being used in a malicious attack.
dependencyinjection@discuss.tchncs.de 10 months ago
It’s the cascading nature of the dependencies. You could install a single package that might directly or indirectly depend on 100’s of other packages, which can introduce bugs into existing code bases which can be difficult to fix as you have no control over another library or dependency.