There are no true monorepo companies

https://graphite.dev/blog/there-are-no-true-monorepo-companies

by fosterfriends • 3 years ago

12 6 3 years ago

pperi11• 3 years ago

This sounds kind of pedantic, considering Google is the most popularly cited monorepo. Curious to know why the author has this perspective

tragic95• 3 years ago

Did you even read the full article? Based on it's definition, Google would be called a polyrepo company.

tomasreimers• 3 years ago

To me, Monorepos are about a separation of concerns (or lack thereof). Something is a monorepo if/only if there is greater than one concern in the repo. (For example mobile + web, backend + frontend, service + server).

When I was at FB, I remember someone used the term polylith to describe our multiple monorepo situation... I suspect that's probably a pretty common situation for people that "have a monorepo"

1letterunixname• 3 years ago

Hey fellow Xeta.

The number of secondary repos was/is declining by merging them into poly-monorepos. For example, opsfiles was/is moving to fbcode.

With good D/VCS tools that can checkout code efficiently, review processes, and CICD testing, there's no real reason to avoid monorepos.

Btw, the FB "hg" was semi-opensourced as sapling. Eden and mononoke still haven't been FOSSed. And, like many Meta dev tool FOSS projects, they don't just build and work OOTB and often have hard-coded Meta-isms like references to internal paths. https://github.com/facebook/sapling

dbradf• 3 years ago

What I really like about having multiple repos is that it encourages bounded context and forces us to put at least a little thought into the interfaces between different systems.

When I have worked in large repos, I have frequently seen poor abstractions where too much code is reaching into other code without clearly defined interfaces that leads to projects that are really difficult to maintain.

david-j-vujic• 3 years ago

I like the suggestions about a more descriptive name, like "multi-project", that I believe describe the thing more clearly. This would probably also remove some of the confusion betweeen the words monorepo and monolith.

Also, I don't see anything bad with an organization having more than one "monorepo" for grouping a number of related projects - an example would be different monorepos for different programming languages. This would probably mean that the organization is a "polyrepo" one (or maybe multi-project).

The Polylith Architecture support these kind of scenarios: one monorepo for all code, or a number of multi-project repos within an organization. There's also tooling support for this architecture, currently for Clojure and Python.

I'm the maintainer of the Python tooling, that is a combination of two Poetry plugins - one with the name "multi-project plugin". Here's the docs for the Python tool: https://davidvujic.github.io/python-polylith-docs/

There are no true monorepo companies

Related Stories