←back to thread

A critique of package managers

(www.gingerbill.org)
109 points gingerBill | 1 comments | | HN request time: 0.001s | source
Show context
Octoth0rpe ◴[] No.45167870[source]
> Each dependency is a potential liability.

I mean, sure. So what does the solution look like? From my perspective it looks like a tool that is able to update your dependencies so that you can easily pick up bug fixes in your dependencies, which sounds an awful lot like a package manager.

> JavaScript is great example of this as there are multiple different package managers for the language (npm being one of the most popular), but because each package manager defines the concept of a package differently, it results in the need for a package manager manager.

This doesn't seem like a strong point to me. Yes, there are things like yarn, pnpm, etc. But IIUC practically all npm alternatives still define packages in the same way (a package.json at the root hosted by npmjs (or your private repo)), and the differences are ergonomic/performance related.

> [that each package manager defines the concept of a package differently] is why I am saying it is evil, as it will send you to hell quicker.

Then I think it's more of a language problem, not a problem with the concept of a package manager.

replies(5): >>45167879 #>>45167968 #>>45167990 #>>45167997 #>>45168723 #
1. zdragnar ◴[] No.45167968[source]
Yeah, yarn and co came about because npm was slow, buggy and didn't honor its own lockfile.

Nowadays it is mostly improved, and the others differentiate by enchantments to workspaces (better monorepo support) or more aggressive caching by playing games with where the installed packages physically exist on the system.

The core functionality- what a package is- has always been the same across the package managers though, because the runtime behavior is defined by node, not the package manager.