Monorepos: Please don’t

Seems like the main point is that you'll still need to add additional tooling (search, local cloning, build, etc) to handle scaling, something you can do just as well with polyrepos. Conversely, for polyrepos, you can add tooling to fix issues with dependency management and multi-project changes/reviews. However, the author figures that monorepos engourage bad code culture and points out that Git is hard to build a monorepo on.

To me this message seems a bit shallow, of course we can build tooling to hide the fact that we have a polyrepo. Given well enough built tooling and consistent enough polyrepo structure (all using same VCS, all being linked from common tooling, following common coding standards and using the same build tooling, etc.) the distinction from having a monorepo is more of an implementation detail.

Given the choice between a consistent monorepo where everyone is running everything at HEAD and a polyrepo where each project have their own rules and there's no tooling to make a multi-project atomic change, I'd go for the former.

Given the choice between identical working environments but different underlying implementations I would go for whatever the tools team think is easier to maintain.

FB has a monorepo for most of the known universe

> is there any real difference between checking out a portion of the tree via a VFS or checking out multiple repositories? There is no difference.

How big is your monorepo? Assume each line of code is a full 80 characters, stored via ASCII/UTF-8. That 67 million lines of code in 5GB. I can fit five of those on a Blu-ray.

> The end result is that the realities of build/deploy management at scale are largely identical whether using a monorepo or polyrepo.

True.

> It might be deployed over a period of hours, days, or months. Thus, modern developers must think about backwards compatibility in the wild.

Depends entire on the application. Lots of changes are deployed within short periods of time with low compatibility requirements.

> Downside 1: Tight coupling

Monorepos do often have tightly coupled software. Polyrepos also often have tightly coupled software. Polyrepos look more decoupled, but pragmatically I can't say I've noticed a much of difference.

> Downside 2: VCS scalability

I've also heard Twitter engineers complain about the VCS. But what is the scope of the author's discussion? 1,000 engineer orgs? Or 20 engineer orgs? Those are vastly different levels of engineering collaboration. I assume the article was not written to cover both of those. Or was it?

---

Ultimately, I think the author implicitly assumed a universe of discourse of gigantic repos with hundreds and hundreds of daily contributors.

When people talk about the spectrum of monorepo vs polyrepo architectures, that is very extreme. For example, last I knew, Uber has more repos than it did engineers. And I don't assume that "polyrepos" always means multiple repos per engineer.

And Google has one that includes the multiverse.

Versioning the client/server interface would've also reduced such risk.