There are no true monorepo companies

True monorepo companies aren’t real - hear me out (and watch Juri's talk here).

If a company uses more than one repo (even if they’re all monorepos), they’re a polyrepo company. And there aren't many (if any) companies truly using just one repo:

For example, you’re an engineer at Meta integrating a feature between Facebook and Instagram: two separate monorepos. It’s highly likely you’ll need to share code between both repos, like type definitions (e.g. users and posts):

// typedefs.ts
export interface User {
  id: string;
  name: string;
  email: string;
}

export interface Post {
  id: string;
  content: string;
  userID: string;
}

The moment you import something as simple as shared types into separate monorepos — you invite classic dependency issues that a polyrepo environment wrestles with. This only scales in complexity when two monorepos share libraries.

The age-old debate of “monorepo” vs. “polyrepo/multirepo” has reached far beyond a simple discussion over the semantic number of repos a company uses. Instead, it’s a debate about the separation of concerns: monorepos in a classic sense handle several concerns in one repository, whereas polyrepos ensure that each repository addresses one siloed concern at a time.

There are tradeoffs between each of the flows: large, multi-project repos require an expansive amount of build and CI/CD tooling, and smaller more siloed repos face problems with dependency management and coordination. But none of this has to do with the number of repos you use - just the organizational strategy you’re using to group code across various different repositories.

Companies like Facebook, Google, and Uber popularized the concept of a monorepo the most by claiming that monorepos are critical for them to develop fast and at scale, citing their massive investments in infrastructure and tooling to make monorepo development possible. Workflows like stacking and trunk-based development are all born out of the monolithic frame of thought - so much so that I’ve seen people refer to monorepos and trunk-based development in the same vein.

What some fail to realize, is that they’re not actually putting every single piece of code into one giant repo - they’re instead strategically organizing code across several large repositories that each address a set of diverse (yet somewhat related) concerns. Depending on your role at the company (infra and IG teams at Facebook for example), you may even work across multiple monorepos that share resources.

But again, this starts to cause confusion - isn’t working across multiple repos a characteristic of a polyrepo company? Perhaps what’s confusing about all of this is the oxymoronic naming of the “monorepo.” Rich Harris, the creator of Svelte, put it plainly, “the interesting thing about a monorepo isn’t that there’s one of it, it’s that it contains many things, whereas a repo contains one thing”.

I strongly believe every company is a polyrepo company by default - some more literally than others. What’s more interesting than the number of repos your company employs, is how many projects or sub-libraries each of your repos manage and how you can better organize your code across multiple repos to better serve your team.

Perhaps it’s time we rename “monorepo” to “multi-service” or “multi-project” repo.