Many new package managers (e.g. cargo) have small differences which often have a massive impact for such situations.
They are still not perfect, but they tend to know it and work on improving it (almost often slow).
The problem tends to be more around missing proper CI setups and workflows(1) and similar. And naturally npm being very easy to use wrongly.
(1): Lock versions, (shallow) review diffs of most dependency bumps, test and build in a sandbox, automatically check CSV/audit databases on frequent basis, don't automatically bump versions of release builds, etc., etc.
> carefully selected but outdated distro repos.
and also:
- inconsistent between distros
- sometimes long term unfixed security vulnarabilities
- (more) incompatibilities between packages and distroes
- unofficial patches to fix security vulnerabilities or compatibility, which not seldom cause future subtle problems, including security problems
-problems to push important security fixes in time
-often not language specific due to the high amount of work needed to properly maintain them
- costly to operate
- an additional attack-able link in the supply chain
- often OS specific
A distro based system is quite nice for distributing programs,
but in my experience it's a nightmare for software packages.
I mean just look at the endless problems distros have with packaging python, npm and shared objects.
Instead I think most dependencies should always be bundled with the program (if anyone can rebuild if needed, i.e. open source) and distros should only package programs, not libraries.
There are some exception. But like less then 10 on most Linux systems, and many could adept by having a well defined non C-FFI interface + bundled support library.