4 ms·

Monorepos have their advantages, as pointed out, one place to review, one place to merge. But it can also breed instability, as you can upgrade other people's

Monorepos have their advantages, as pointed out, one place to review, one place to merge. But it can also breed instability, as you can upgrade other people's stuff without them being aware. There are ways around this, which involve having a local module store, and building with named versions. Very similar to a bunch of disparate repos, but without getting lost in github (github's discoverability was always far inferior to gitlab) However it has its draw backs namely that people can hold out on older versions than you want to support.

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 ago
  I 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.

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 ago
I 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.