3 ms·
> But it can also breed instability, as you can upgrade other people's stuff without them being aware This is why Google embraced the principle that if somebod
by dkarl 2y ago
> But it can also breed instability, as you can upgrade other people's stuff without them being aware
This is why Google embraced the principle that if somebody breaks your code without breaking your tests, it's your fault for not writing better tests. (This is sometimes known as the Beyonce rule: if you liked it, you should have put a test on it.)
You need the ability to upgrade dependencies in a hands-off way even if you don't have a monorepo, though, because you need to be able to apply security updates without scheduling dev work every time. You shouldn't need a careful informed eye to tell if upgrades broke your code. You should be able to trust your tests.
- KaiserPro 2y agoI mean yes, that is an approach. However that only really works if people are willing to put effort into tests. It also surmises that people are able to accuratly and simply navigate dependencies. The issue is that monorepos make it trivial to add dependencies, to the point where if I use a library to get access to our S3-like object storage system, it ends up pulling a massive chain of deps culminating in building caffe binaries (yes, as in the ML framework.) I cannot possibly verify that massive dependency chain, so putting a test on some part which fails is an exercise in madness. It requires a culture of engineering discipline that I have yet to see at scale.