> But this also means it is easy for a commit into a dependency to break a lot of downstream projects as it is not possible for the person maintaining the depen

> But this also means it is easy for a commit into a dependency to break a lot of downstream projects as it is not possible for the person maintaining the dependency to test all the dependent projects, unless it is acceptable to rely solely on test automation. You can invert this sentence to imagine an alternate world: If you are able to rely completely on test automation, then it becomes possible for a person to commit a change to a dependency without breaking all downstream projects. Companies with successful monorepos live in that alternate world. Yes, it requires heavy investment in automated testing: you need a culture where every engineer writes tests for all code they write and edit all the time, you need good automated test tooling, and you need to pay for the servers to run the tests all the time. But if you have that, you get to avoid the hellscape of bit rotting dependencies that no one can touch because too much of the world sits on top of it. I used to work at EA, which at the time had a separate Perforce repo for every game. There was a big push to reuse libraries across multiple games, but game teams had control over when they updated those libraries. I spent six months of my life doing nothing but integrating upstream changes in some libraries into various game repos that were using them. Not entirely coincidentally, I left EA not too long after.