Agreed about the lack of monorepo tooling. There's just not that much out there. A couple of other links I didn't see in the awesome-monorepo:

- https://github.com/facebookexperimental/mononoke - I hear this is a real thing and not a science fair project

- https://github.com/bors-ng/bors-ng - Needed in a monorepo to handle high arrival rate of commits / merges

What problems specifically did you see? Was this because the repo was too large?

I understand at google scale you'd need lots of tooling but why at a smaller scslr of merging a dozen small repos?

The biggest problems are always cultural. Most monorepo workflows really reinforce constant integration, and once you have separate teams with separate managers, I've always witnessed constant conflict that ended up trying to establish spheres of control. It's bizarre - but it's something I've seen at pretty much every place I've worked at.

With all that integration, your single CI toolchain is front and center since everyone's success or failure is tied to it. While projects like bazel exist, how many developers do you know work with bazel every day? I no nobody who does. And most want documented IDE support and ease of use, not some optimal CI workflow. I've found gradle to be OK, but even that kind of pushes everyone toward using Jetbrains tooling. In the end, almost real monorepos have significant custom CI tooling that wires together different toolchains, and, they may have to maintain custom tooling for use in developer machines. And that custom tooling can get expensive to maintain as the project scales up.

Thanks