4 ms·

There are no true monorepo companies

12 points by fosterfriends 3y ago

pperi11 3y ago
This sounds kind of pedantic, considering Google is the most popularly cited monorepo. Curious to know why the author has this perspective
- tragic95 3y ago
  Did you even read the full article? Based on it's definition, Google would be called a polyrepo company.
tomasreimers 3y 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 3y 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 https://github.com/facebook/sapling
dbradf 3y 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 3y 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/ https://davidvujic.github.io/python-polylith-docs/

12 points by fosterfriends 3y ago

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

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

tomasreimers 3y 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 3y 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 https://github.com/facebook/sapling

dbradf 3y 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 3y 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/ https://davidvujic.github.io/python-polylith-docs/