This fixer would have to walk the dependency tree. What if something breaks contract in the middle, something I do not control? That sounds like a huge burden on developers with lots of risk.
Why opt out of proper dependency management?
Why opt out of proper dependency management?
user/my-scrap@414
Remember that the language itself works like a merkle tree and every scrap can be cached anywhere. To keep the language and tooling extremely simple, I think this works well enough.
> What if something breaks contract in the middle, something I do not control?
Everything is strongly typed, so there are certain guarantees about how things can break and update. You can easily make tooling that never makes breaking changes.
People can always introduce implementation bugs into their code though, but that's inevitable even with dependency management.
> That sounds like a huge burden on developers with lots of risk.
I will try my hardest to reduce that burden. I think I can put some sane defaults in the tooling surrounding the language to obviate the need for traditional dependency 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
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.