Let's talk about Monorepos

This post is the first part of a series that I will be updating on the use of monorepositories. Here we will only define what it consists of and discuss the advantages and disadvantages that we may find implementing them.

Let's kick off with interesting information

Something that might interest you as you read this article is to know that many large and well-known companies use monorepos. Big names such as Google, Facebook, Microsoft, Twitter, Uber etc...

Knowing this, the suspicion grows that it might be something worthwhile and perhaps appropriate for your projects. There is no absolute or perfect solution for every project, you will first need to understand the usefulness and then decide if it is an added-value in the context where it is applied.

Sounds good but… what is it!?

The name implies that it is related to repositories and actually, this sentence would be more correct by making the word "repositories" to it's singular form, hence the "mono".

In a mono-repository, what we could think of a typical set of repositories for different projects unified into a single one.

It is indeed a single repository where multiple projects are published but they remain isolated from each other. Please do not confuse Monorepo with monolithic, they are very different subjects.

Let's take the time to ask some questions which we will answer later in this post.

• Why would we split several projects into one single repository?
• What is the point and why would we make such a change?
• And the important stuff..., is this worth it?

Advantages of implementing a Monorepo

As specified before, there is no single solution for all kinds of projects, so we can list the advantages and disadvantages and in the end draw some conclusions that can help us reflect if it is really worth it for our context.

Dependency Management

Since different applications and libraries are included in the same repository, the first thing we can conclude is that dependency management can become more pleasant and it is possible to avoid the chaos that we often find in migrations or incompatibilities between different projects.

We are able to define base dependencies for all the projects in general and this will allow us to get better visibility into installed packages. Speaking of installing, it also avoids installing dependencies for each project every time we update a version.

Configuration and Consistency

If there are code and configuration standards defined for applications and libraries in general, why should we configure and reconfigure our projects? We can include base configurations that can be shared among our projects inside our monorepository, be it eslint, tsconfig, jest, prettier, webpack or any other configuration typically found in projects.

Visibility

By having multiple libraries and applications included in a single repository, there is an important improvement in the ease of viewing different projects, allowing developers from different teams to analyse different solutions to similar problems, to gain an interest in code standards, to see if there is anything "already implemented" or that can be reused.

Versions & Build

It has probably happened to us many times to go through the frustration of updating a library in a certain repository, having to wait for a build of the pipeline, publish, change the version in the repository of the consuming application, wait for an install and verify that everything is correct. Mono-repositories can be of great value in this aspect because everything becomes simpler from the moment we can find all dependencies | projects in the same place, facilitating builds, releases, etc.

General modifications

When I talk about general modifications, we can easily relate to refactors. Do we have new requirements that apply to multiple projects? Isn't it simpler to change it just in one repository, test it on the fly and make a general commit without worrying about losing time with builds, multiple pulls, commits, etc.? Speaking of pulls... We also can't forget that it is much simpler to update projects and libraries with a general pull, we can get all the changes from several teams at once.

Seems ideal right? But as I have repeated here several times, not all solutions are optimal for all contexts, so in an unbiased way, we should also explore some disadvantages that we might encounter when implementing a monorepository.

Disadvantages of implementing a Monorepo

I have read many posts in the past about monorepositories that expressed only advantages forgetting that there are some factors that may be inconvenient for many. So let's explore what might be a minus when using monorepositories.

Access is not restricted

Having some or many applications and libraries in the same repository can become a security problem if we want to restrict access or viewing among several teams. Once the checkout is done, all teams will have access to everything and that can be inconvenient.

Git checkouts can be very heavy and time consuming

There are companies that include the entire codebase in a single repository, this is not necessary in most of the scenarios, but if the repository grows too big, just imagine the time to perform a simple checkout and how much it might weigh in terms of size.

Build time

Of course there are strategies and ways to get around the build time for CI, it would be pretty crazy to have to build every project every time a pull request is approved. However, this will make setting up the pipeline and automated builds more complex and can be a difficult task to implement a process for creating scripts dedicated to this purpose.

GIT performance

Let's imagine hundreds of commits per day in one single repository... The history can become chaotic and GIT management a headache if it is not well defined and understood by the teams.

Conclusion

In this first post about monorepositories, we can form some ideas at advantages and disadvantages when implementing monorepos. All information is scarce when it comes to designing an architecture for a system that we are not used to, and we should always take into account the context of our projects to understand if it will really be a benefit for us. There are many success stories and diverse opinions on this subject, I invite you to read not only this post but to get informed in general and perhaps try to use a monorepository via a POC to have a vision based on real experience.