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"
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
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.
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/
6 comments
[ 3.0 ms ] story [ 31.2 ms ] threadWhen 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"
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
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.
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/