Last year at Proton, we migrated from a polyrepo architecture to a monorepo architecture to make it easier to manage the packages that are part of our front-end web application stack. We’d been facing problems for some time, and after considering our options, we decided that a monorepo would be the most suitable solution. This article explains the problems we faced with our polyrepo setup, explores the benefits of a monorepo setup, and describes our journey from polyrepo to monorepo.
Before going further, when I say “polyrepo” and “monorepo”, this is what I mean:
- Polyrepo: A system of source code modules that have dependencies between each other but are separate version control repository instances.
- Monorepo: A system of source code modules that have dependencies between each other but all live under a single version control repository instance.
I’m going to say “Git repositories” or just “repositories” instead of “version control repositories” from here on out. And, to be clear, Git is not a prerequisite of monorepo architecture.
