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

▲

bluGill 4 days ago | parent | next [-]

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

▲

Octoth0rpe 4 days ago | parent [-]

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.

	▲	wpollock 4 days ago \| parent [-]
		The Boost library went the audit route, but AFAIK, few other repositories (or libraries) have done that. I believe it's a cost and lack of manpower that prevents that. You may not have the time to audit dozens/hundreds of dependencies pulled into your projects, but there's still something you can do. For Rust/Cargo, you can run tools that check every dependency against a vulnerability list. As you have source of dependencies, you can also run static code analyzers/auditors to scan for code smells, lack of unit tests, etc. For Java, I use the OWASP plug-in of Maven to check dependencies for security vulnerabilities. I bet other languages' package managers/build tools have similar plug-ins. Some auditing is better than none at all. You shouldn't do no checking just because you can't full auditing!

▲

zdragnar 4 days ago | parent | prev | next [-]

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.

▲

gingerBill 4 days ago | parent | prev | next [-]

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

▲

Octoth0rpe 4 days ago | parent [-]

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

	▲	gingerBill 4 days ago \| parent \| next [-]
		It makes it worse in my opinion, not better. Because it leads to the problem that other package managers don't agree on what a package is, and it might even lead to the need for an external build system to co-ordinate all of it too. It's a never-ending problem, and is now even worse.
	▲	dismalaf 4 days ago \| parent \| prev [-]
		And if the language does provide the definition?

▲

smw 4 days ago | parent | prev | next [-]

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

Exactly! Who has the time or the discipline to do that manually?

▲

Sesse__ 4 days ago | parent | prev [-]

> I mean, sure. So what does the solution look like?

Obviously taking on fewer such liabilities?

▲

Octoth0rpe 4 days ago | parent [-]

The article specifically excludes this as _the_ solution to the problem:

> I am not advocating to write things from scratch.

and is clear in its target:

> That’s my general criticism: the unnecessary automation.

Yes, fewer dependencies is a solution, but it does not seem to be the author's position.

	▲	gingerBill 4 days ago \| parent [-]
		That is my position... again, I am not sure how you got this conclusion from the article. The "I am not advocating to write things from scratch" is more of a caveat to the people I know will comment NIH nonsense rather than anything productive. But yes, my position is minimize dependencies and slow and carefully vet them too, and do not automate this process.