A critique of package managers

> "This is the automation of dependency hell. The problem is that not everything needs to be automated, especially hell. Dependency hell is a real thing which anyone who has worked on a large project has experienced. Projects having thousands, if not tens of thousands, of dependencies where you don’t know if they work properly, where are the bugs, you don’t how anything is being handled—it’s awful.

This the wrong thing to automate. You can do this manually, however it doesn’t stop you getting into hell, rather just slow you down, as you can put yourself into hell (in fact everyone puts themselves into hell voluntarily). The point is it makes you think how you get there, so if you have to download manually, you will start thinking “maybe I don’t want this” or “maybe I can do this instead”. And when you need to update packages, being manual forces you to be very careful."

I sympathise with this, but I have to respond that we have to live within existing ecosystems. Getting rid of npm and doing things manually won't make building SPAs have fewer dependencies, build would be incredibly slow and painful.

There already is a (partial) solution to dependency hell: Nix.

It will at least massively help prevent things from breaking unexpectedly.

It won't prevent you from having to cascade a necessary upgrade (such as a security fix) across the entire project until resolution/new equilibrium is achieved.

My solution to the latter is simply to try to depend on as few things as possible. But eventually, the cancer will overtake the project if it keeps growing.

Source: Have worked on a million-LOC Ruby app

Packages themselves are not bad. NPM is just fine - so long as you don't let it do dependency resolution and lock the version of every package. Note that this means you have to get notified when each package is updated (how!) and make a decision on how to update it (or if you decide not to update make a decision to maintain it).

The other thing is your package manager cannot go out to the internet randomly. You need it to download from a place you are comfortable with (which might or might not be the default) existing as long as you need packages, and that will keep the versions of packages you want around. If you are a company project that means an internal server/mirror because otherwise something you depend on will disappear in the future. (most of they decide nobody is using it, delete it, but sometimes it is discovered the thing is an illegal copyright violation - but you have ask your lawyers what this means for you - perhaps a license is easy to get)

> Getting rid of npm and doing things manually won't make building SPAs have fewer dependencies, build would be incredibly slow and painful.

You don't think making adding dependencies incredibly slow and painful would make people have fewer of them?

Some years ago, I had to reproduce a neural model build that had only been done previously by a single colleague on her laptop, not using a package manager.

Part of my reproducing the build was to conduct all the library downloading in a miniconda environment, so at the end I had a reproducible recipe.

Is the original author seriously claiming that anybody was better off with the original, "pure" ad-hoc approach?

You would decrease number of dependencies yes. However your dependencies or your code would then become huge.

Same number of lines but in fewer dependencies.

In the context of my team, us getting rid of npm wouldn't change the whole SPA ecosystem. Or the various requirements we have that effectively mandate SPA like applications.

But in the context of newer ecosystems or ones that are more tightly controlled things might be different. For example if apple massively expanded the swift standard library and made dependency management painful, iOS apps might end up having fewer dependencies.

Yes, because of human limits of time and of skills.

I remember installing software in the early 90s: download the source code, read the README, find and download the dependencies, read their READMEs, repeat a few times. Sometimes one dependency could not compile because of any incompatibility or bug. Some could be fixed, some couldn't. Often everything ended up with a successful compilation and install and in one day of work I could have what I'm getting in a few minutes now.

Actually those were small programs by today standards. My take is that we would achieve less if we have to use less dependencies.

By the way, the last time I compiled something from source was yesterday. It was openvpn3 on Debian 13, which is still unsupported. TLDR, it works but the apt-get are a little different from the ones in BUILD.md

> Getting rid of npm and doing things manually won't make building SPAs have fewer dependencies, build would be incredibly slow and painful.

Honestly, I don't think this is true in the slightest. Rather, I hypothesize that people want to use such tooling and think the alternatives are slower, which I don't think is true.

If people actually did use fewer dependencies, people would have actually have websites that didn't take ages to load and were responsive.

So the existing ecosystems are just bad.

Nix isn't a solution to the problem of package managers. It just a better way to package management system, which thus makes it easier to go to dependency hell. So I'd argue it puts fuel on the flames.

The solution is just to depend on less and manage them manually.

If we depend on less then we are capping what we can build to only what we can write and manually integrate. This is dis-empowering.

I'd argue quite the opposite. You can build a lot more than you think, you just need to be encouraged.

I don't think that is a solution. In fact I don't think there are any "solutions". I do think there are tradeoffs though.

if you depend on more, you are capping what you can build to only what you can manage to get working and integrate, plus you also lose control over the code; for me personally, it's a lot easier to write a complicated algorithm, than it is to figure out a complex build system for a random library in the wild (with few exceptions like miniaudio); and it's especially worth it, because when i understand the problem, i can usually define a way better api for my usecase than any library writer can