A critique of package managers

> 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.

> So what does the solution look like?

There are no solutions, only trade-offs. And the point is that not everything needs to be, nor ought to be, automated. And package managers are a good point of this.

And yes, a language with an ill-defined concept of a package in the language itself is a problem of the language, but the package managers are not making it any better.

> And yes, a language with an ill-defined concept of a package in the language itself is a problem of the language, but the package managers are not making it any better.

If a language does not provide a definition of a package but a package manager _does_, then I would say that that package manager did make that aspect of the problem better.