What is a monorepo?
A monorepo is a version-controlled code repository that holds many projects. The opposite is a polyrepo design. In a monorepo, many dependent source trees are stored in a single source code repository, which makes for some interesting benefits, as well as some perhaps obvious drawbacks. This article talks about what a monorepo is and when you would want to use one.
Why would anyone use a monorepo?
According to Adam Jacob, the former CTO of Chef:
"The default behavior of a polyrepo is isolation - that's the whole point. The default behavior of a monorepo is shared responsibility and visibility - that's the whole point.
You might initially think that as an application becomes more complicated, you would want to break that code up into smaller pieces. This has its merits of course, but what about when the smaller pieces become dozens? Hundreds? Thousands? It becomes a herculean effort to understand all the many cogs of the application, and to know where to look for any dependency.
Note: It's worth a read to check out how Google does monorepo.
What are the pros and cons of the monorepo?
Let's look at some of the pros and cons of using a monorepo.
|Cross-project changes||Huge number of tests/slow testing|
|Dependency management||Developer onboarding/learning curve|
|Code access||Custom CI/CD tooling|
|Code reusability||May need custom VCS|
|Less deprecation||Poor performance|
|Broader awareness||Broader breakage impacts|
|Strong and implicit continuous integration||Code review noise|
How can you begin to use a monorepo?
Your first step in getting started is to get over the fear of grouping codes that are related, but different into one place. Embrace the benefits and acknowledge that there are different problems than using a polyrepo, but not more problems.
Interested teams should take a sit, crawl, walk, run approach to monorepo. Address easier projects first, and with proper understanding and demonstration, momentum should follow.