• 

  Ray Luxembourg

  A passionate software developer who loves what he does. Fluent with JavaScript, TypeScript, React, Angular, Node.js. Specializing in large-scale web application architecture and development.

  More posts by Ray Luxembourg.

Ray Luxembourg

Recently I was working on motivating more teams, to start using monorepo technology with very clear reasons, and those reasons I want to share with you.

First miss conseption is,  Monorepo is the same as monolith.
This is completly depends on your usage of the monorepo.

A monolith could be managed in a monorepo. But a monolith could also be split into multiple repositories. Similarly, a monorepo could be used with microservices instead of a monolith.

The format of this post will be as follows, I will present a challenge, and will try to show how it is handle with both a multi and monorepo approach if possible.
I will not cover CI/CD sepertly as it is mentioned in the 2nd challenge but i would just say that Monorepo is much more efficent at CI/CD then multi repo.

First challenge: Repository Managment

Let's start with the complexity growth.
Let's say you have currently 10 repositories in your company and all of them running in GitLab and with a specific node version in GitLab-ci configurations.

First challenge: Multip Repo

The company requires that we upgrade our node to the latest LTS.

The first approach, If you point all your repositories to the latest tag and updated that latest in one place, expect unexpected issues to arise as you might have to revert due to projects not being ready for migration yet.

The second approach, similar to O(n) the number of work you have to do is super related to the number of repositories you have, now go and manually migrate each repo to support the latest node.

Now if you continue this multi-repo approach you can see how your complexity increases over time or with the scale of the product.

First challenge: Monorepo

Here it's a bit more simple, no matter how many projects you have in your monorepo, you have only 1 CI configuration and 1 node version.
Moreover, when you upgrade this version on a side branch, you can run tests for all projects and see if someone stops working O(1).

2nd Challenge:  Relationships between repositories

2nd Challenge: Multip Repo

When working with multi repositories the relationship between projects can be unclear and this might affect your testing strategy and stability overall as a change in 1 place can relate to another and you have to build a testing plan to verify changes.
You would typically upgrade a software version and then pull the new update in another software and run pipelines for both in order to check that everything works.
Pay attention to O(n) complexity here because the more consumers of Lib A the more work you have to do to make sure everything works properly.

2nd challenge: Monorepo solution

On the monorepo side, making a change that is related to other projects, can be easily detected with advanced tools like Turborepo and Nx which will trigger pipeline for affected areas and therefore will save time and increase overall stability as you will not be able to push changes unless pipeline passes.
If everything passes, you can automatically update all of the software versions as part of the natural flow of your pipeline.

3rd Challenge: Code duplication

3rd Challenge: Multip Repo

Code duplication awareness in a multi-repository approach is harder as you have to cross-check all repos and again it's more intensive with more repos.
To detect duplicate code across multiple repos, you need either some technological solution which I am not aware of at the moment or having a domain expert that is aware of all x repositories in the company and in other words do manual labor.

3rd challenge: Monorepo solution

Since all your projects live in a monorepo, using tools like Sonarcube for example, we can analyze the monorepo and detect  code duplications.
Another way is to use IDE's like webstorm that can also detect code duplications.
After you discover code duplication, you can refactor it into library with other common elements and reuse it.

4th Collaboration, Domain expertise growth, transperancy.

4th Challenge: Multip Repo

On a multip repository apporach, a developer is not exposed to other projects unless he is part of the project and therefor he is less exposed by nature to different domains and his knowledge is less effectivly used, this affects collaboration between multiple projects, developer domain growth with less exposure is equal to less potential growth.

4th challenge: Monorepo solution

Naturally in a monorepo you are more aware of relationship between projects, you can see open pull/merge requests as part of your daily routine without leaving you repo.
This creates an oppertunity for developers to share knowledge, potentially getting more invovled in other areas and therefor growing their knowledge and domain expertise.

You will notice git platforms like gitlab starting provide more and more features to help manage monorepo's which is great indication about the industry opinion on monorepos.

Last words, Monorepo is continuesly optimized and not labor free solution you should take this into considertion.

You should activly optimize you monorepo until you get your desired results and i could admit that it is still easier to maintain 1 repo instead of n amount of repos.

Best of luck!