There are no true monorepo companies(graphite.dev)
graphite.dev
There are no true monorepo companies
https://graphite.dev/blog/there-are-no-true-monorepo-companies
6 comments
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.
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.
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"
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"
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
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
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/