I stand by the opinion that allowing multiple dependency versions was a major mistake that lead to both ballooning node_modules and abandoned packages getting caught up in your dependency tree just waiting for a malicious actor to hijack them.
In pip or composer, those dependencies have to be forked or removed or they will create conflicts.
Re:Four Eras of JavaScript Frameworks
by goodoldneon on Wednesday April 27, 2022 @03:19PM
(#31184536)
Multiple dependency versions causes problems but the alternative is pretty bad, too. You can get stuck on older versions of a dependency because newer versions have a transitive dependency that causes a conflict with a different direct dependency
Re:Four Eras of JavaScript Frameworks
by MereInterest on Thursday April 28, 2022 @07:50AM
(#31191394)
I feel like that's at least a solvable problem that makes itself obvious when the dependency is added. Multiple coexisting dependency versions sounds like a ticking time bomb to me.
Suppose I use a LibraryX that provides DataTypeX, and most of the functions in my project operate on DataTypeX. I later add another LibraryY, because it provides a utility function returning DataTypeX. I should be able to take the result and use it anywhere in my existing code. However, if my direct dependency on LibraryX is a different version than transitive dependency on LibraryX through LibraryY, then it may not have the same functionality. In trying to avoid a problem at compile-time, the package manager has introduced a huge potential problem at run-time.
Since those version ranges of X don’t overlap, it isn’t possible to satisfy both A and B’s requirements. Node can handle this