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.

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

If only it where that easy.

Often the update isn't source compatible with the package that uses it so you can't update. There are some projects I use that I can't update because I use 6 different plugins, and each updates to the main project on a different schedule on their own terms - meaning the only version I can use is 10 years out of date and there appears no chance they will all update. (if this was critical I'd update it myself, but there are always more important things to work on so I never will in practice)

Sometimes a package will change license and you need to check the legalese before you update.

Sometimes a package is hijacked (see xv) and so you really should be doing an audit of every update you apply.

I agree with all of the problems that you're highlighting, but would say that all of those problems exist whether or you're doing manual dependency management or using a package manager.

The solution IMO (which is non-existent afaik) would be to integrate some kind of third party auditing service into package managers. For example, for your npm project you could add something like this to your package.json:

` "requireAuditors": [ { "name": "microsoft-scanning-service", "url": "https://npmscanner.microsoft.com/scanner/", "api_key": "yourkeyhere, default to getting it from .env" } ] `

And when you npm install, the version / hash is posted to all of your required auditor's urls. npm should refuse to install any version that hasn't been audited. You can have multiple auditing services defined, maybe some of them paid/able to scan your own internal packages, etc.

I've thought about building a PoC of this myself a couple of times because it's very much on my mind, but haven't spent any time on it and am not really positioned to advocate for such a service.