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.
Comment on When "Everything" Becomes Too Much: The npm Package Chaos of 2024 - Socket
QuazarOmega@lemy.lol 10 months ago
This is hilarious, but now I’m wondering, what would a saner package manger look like?
jeffhykin@lemm.ee 10 months ago
QuazarOmega@lemy.lol 10 months ago
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
Masterkraft0r@discuss.tchncs.de 10 months ago
have a look at nix
azertyfun@sh.itjust.works 10 months ago
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 aboutcargo
but haven’t used it enough myself to have a strong opinion.Jesus_666@feddit.de 10 months ago
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.
FlorianSimon@sh.itjust.works 10 months ago
Is that still a valid argument in 2024? The standard library has grown since the leftpad scandal. JS does have standard leftpad now.
It’s a genuine question, I no longer write Javascript for a living.
Jesus_666@feddit.de 10 months ago
Compared to other languages it’s still very barebones – but admittedly some of the bloat is also because the JS world is kinda set in its ways. I still see people use jQuery for basic selector queries and SASS for basic CSS variables.
Another factor is that developers these days assume that users have fast unmetered connections. Loading 800 kB of minified gzipped JS from ten different domains is seen as no big deal. When the cost of adding piles of dependencies is considered nil there’s no impetus to avoid them.
FlorianSimon@sh.itjust.works 10 months ago
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.
azertyfun@sh.itjust.works 10 months ago
It’s saner, not perfect. With virtualenvs it does basically what you describe except that it re-downloads everything for every virtualenv, but that does not typically matter much since it’s not downloading a billion dependencies.
With NPM there’s no choice but to have hundreds of duplicates installed for every project, that’s not just inefficient but it is a security, maintainability, and auditability nightmare.
FlorianSimon@sh.itjust.works 10 months ago
NPM is definitely saner for that use case because it works out of the box. Pip is not because it is based on shakier foundations. With NPM, you don’t get to a point where you rely on things to work correctly, and they suddenly don’t and you have trouble understanding why. And it does not force me to look at its nuts and bolts to allow me to work with it.
I can afford big node_modules directories, even if it’s not optimal. It’s still small compared to other projects I’ve worked on with other technologies. Remember the order of priority of things: make it work >> make it efficient. Software engineering is about delivering software, it’s not an art. It doesn’t have to be pretty everywhere.
I will concede that NPM is not perfect. Despite its flaws, I love how Conan solves the issue we’re talking about.
QuazarOmega@lemy.lol 10 months ago
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?
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
labsin@sh.itjust.works 10 months ago
Other package managers, like nuget, throw errors if all dependencies on a package cannot be met by a single version.
This is probably the result of it copying all libraries in the same output directory and that .net cannot load 2 different versions of the same library so more an application restriction.
The downside of this is that packages often can’t use newer features if they want to not block the users of that library and that utility libraries have to have his backwards compatibility so applications can use the latest version while dependent libraries target an older version. Often applications keep using older versions with known security issues.
QuazarOmega@lemy.lol 10 months ago
Damn, sounds like a big headache x.x
azertyfun@sh.itjust.works 10 months ago
npm
downloads every dependency recursively. Ifa
depends ond (= 1.2.3)
andb
depends ond (= 1.2.4)
, then both versions ofd
get downloaded intoa
andb
’s respectivenode_modules
.All other package managers I’m aware of resolve dependencies into a flat list then download, and you can only have one version of the same package on your system.
QuazarOmega@lemy.lol 10 months ago
You mean npm duplicates even if the the two dependency versions are compatible?
That couldn’t be, right? Otherwise, if you installed two packages that rely on different incompatible versions of another package, one of the two would break. Reading a bit they should check for “satisfiability”, I found some really interesting things on the topic looking around:
BrianTheeBiscuiteer@lemmy.world 10 months ago
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.”