So the issue is see with lack of dep management...
1. My code depends on dep A and B, which also depends on A.
2. A has some issue, so I update my reference, but B does not.
3. Given dependencies are bundled, B still contains the bad A.
So how can I updated the A used by B? (Without effectively forking B) This is more a problem with bundled or censored dependencies than the lack of dependency management. Dep Mgmt aims to solve this issue by having only one copy of a dependency
Except in many dep management systems they purposefully don’t keep only one copy to allow multi versions to run side by side and other benefits like having a deliberate piece by piece upgrade of everything in the dependency tree. Forcing all deps to be on the same version of all other deps sounds like it would cause more problems than it would solve.
Also the ideas of immutable deps mean this property of “duplicated” deps comes naturally.
I think many bugs can come from what you propose. A large dev tree would need everyone in the tree to coordinate to upgrade all at once. That seems basically impossible for any dep tree. Especially in a system where the deps are small code snippets like this one. Even small programs can have 1000s of deps.
Why are you implying that this model is “normal” dep management?
If the “old” A has a severe vulnerability and the “new” A has breaking changes - then there is no solution other than to avoid/replace/fork B until B is upgraded.
1. My code depends on dep A and B, which also depends on A.
2. A has some issue, so I update my reference, but B does not.
3. Given dependencies are bundled, B still contains the bad A.
So how can I updated the A used by B? (Without effectively forking B) This is more a problem with bundled or censored dependencies than the lack of dependency management. Dep Mgmt aims to solve this issue by having only one copy of a dependency