I think the biggest problem here is that git (out of the box) is not well suited to a monorepo. But in terms of the reasons in "The case against monorepos": >

I think the biggest problem here is that git (out of the box) is not well suited to a monorepo. But in terms of the reasons in "The case against monorepos": > Reason #1. Monorepos go against single-team ownership principles I think it's up for debate about whether or not single-team ownership is desirable. But even if it is, I don't see the difference. Just have teams own their directories within the monorepo. If you want to enforce that a team owns a particular part of the repo, just put some rules into the code review tool to ensure that a change to that component can't be merged without someone from that team reviewing/approving it. > Reason #2. Monorepos encourage bad practices involving massive refactoring Again, this just appears to be the author's opinion that massive refactoring is somehow problematic, without providing much of an argument against it. If you're changing service APIs, then sure, you need to be careful about the order in which you roll out changes. But if you're changing the APIs of shared libraries, then being able to do a single large refactoring is absolutely valuable. > Reason #3: Small repositories are better than large ones This is just a tooling issue. You can still separate projects by directories, and if your tools allow you to just check out a subdirectory, or if you have some sort of virtual filesystem on top of your source control, then you don't have to pay the penalty of pulling down the entire repository.