Some people who advocate for huge monorepos, like Google has, tend to forget that Google has whole teams building tools just to wrangle the huge singular codebase for refactoring and testing.
It’s less about why monorepos are good, and more about why on Earth would you split a product up over hard repo / tooling boundaries. Perhaps a Big Brain could get those boundaries right. I can’t, so when I need to move the boundary I would rather it was done by editing code inside a repo than coordinating changes between micro products.
I’m obviously describing one scenario. What are the counter examples for where hard polyrepo boundaries are helpful? When your team are all IC1s?
The trouble is, you're often left unwinding a half-dozen layers of abstraction, and in many cases experiencing what looks like some sort of quantum code interaction, where changes in one part of the codebase seem to impact completely unrelated bits of code which now fail tests.
The polyrepo + microservices approach helps enforce boundaries. It also makes rapid iteration easier with more limited tooling, because my code can no longer blow up someone else's code -- a problem which can be solved with dev toolchains, but those toolchains take a non-trivial amount of resources to support.
I do agree, when you need to move boundaries, or need to refactor across multiple packages at once, a monorepo + monolith is great. (A monorepo + microservices can introduce many of the same problems as a polyrepo + microservices, though.)
This perfectly sums up all of the microservice apps that I’ve had the pleasure of working on, with the exception of issues being caught by tests. Typically you get either silent production data corruption or a seemingly unrelated error in the UI x weeks down the line.
At $work i see lots of projects leaving the monorepo due to that very mess.
The problem is that services outside have other CI and maintenance issues that wouldn’t happen in the monorepo. But monorepo got so messy that it got unbearable.
The proper solution would be to have a dev teams dedicated to tooling for it, the org has the resources, but it’s just not investing enough in that area.