Monorepo vs Multirepo
(aka: “The use-case matters”)
If you have a clear fit to one of the extremes, — “Loosely coupled highly distributed teams with well documented APIs”, or “Small local project with no dependencies, that only I work on”, for example, then hey, the choice is easy.
Otherwise, it really really depends on your use case, because, there really is no “best of both worlds” option. For every broken dependency that your Monorepo prevents, you have library management and versioning issues that multirepo prevent
Peter describes it best as
If you have a clear fit to one of the extremes, — “Loosely coupled highly distributed teams with well documented APIs”, or “Small local project with no dependencies, that only I work on”, for example, then hey, the choice is easy.
Otherwise, it really really depends on your use case, because, there really is no “best of both worlds” option. For every broken dependency that your Monorepo prevents, you have library management and versioning issues that multirepo prevent
Peter describes it best as
“You could certainly tool up around a multirepo to make multiple repos act more like a single monorepo … establish a consistent toolchain, etc. across all repos to reduce the costs of making changes in other repos. But at that point its not clear what benefit you are getting from multiple repos unless there are other reasons to have some code in separate repos.”
“ Or, in a monorepo, you could use branches to mimic the local stability you get in a multirepo — every project would live in a longlived branch and only merges changes from other projects when needed. But then you get all the potential for irresolvable diamond dependencies preventing you from upgrading when you actually want to.”
Comments