While that may be true, I'm not convinced it is a given. Any complicated enough monorepo requires complex CI/build tools, and Bazel/Blaze exist for a reason ...
The question is: which requires less cost in order to deliver business value? In my experience, on the teams I've been so far, the answer has been monorepos — but I don't know everything.
“You'd need a way to run all tests in all repos reflecting a new change.”
You really shouldn’t have to run every test on every product. Or really any other repos. Use semantic versioning, pin your dependencies, don’t make breaking changes on patch or minor versions.
Pinning your dependencies is an antipattern (or at least in the eyes of many people who support monorepos it is).
It results in one of three things:
1. People never update their dependencies. This is bad (consider a security issue in a dependency)
2. Client teams are forced to take on the work of updating due to breaking changes in their dependencies. If they don't, we're back at 1.
3. Library teams are forced to backport security updates to N versions that are used across the company.
But really, the question to ask is
>don’t make breaking changes on patch or minor versions
How can you be sure you aren't breaking anyone without running their code? You can be sure you aren't violating your defined APIs, but unless you're perfect, your API isn't, and there are undocumented invariants that you may change. Those break your users. Monorepo says that that was your responsibility, and therefore its your job to help them fix it. Polyrepo says that you don't need to care about that, you can just semver major version bump and be done with it, upgrading be damned.
No semver means that you, not your users, feel the pain of making breaking changes. That's invariably a good thing.
At AMZN, which has 1000s of separate repos, 1) was the general case, with 2) occurring whenever there was a critical security issue in some library that no one had updated for years. The resulting fire drill of beating transitive dependencies into submission could occupy days or weeks of dev time.
When you change a project, you have to test the effect of your changes on downstream dependencies. Semver is wishful tthinking. Even a change that _you_ think is non-breaking could break something. Saying "well the downstream team was using undocumented behaviour so it's their fault" doesn't really hold much water when your team is Driving Directions and the downstream team is Google Maps Frontend and your change caused a production outage.
