What is a monorepo?

'A monorepo is a single repository containing multiple distinct projects, with well-defined relationships '

Nrwl creators of NX. .

When I think of a monorepo, I think of relationships in Databases. Complexity reduced to very simple directions that point you to the right details when needed. If you've ever worked with a large database that has no form of UML diagrams or an architectural representation of exactly what it contains and what entity is related to which one then you might understand the importance of monorepos.

The current and most adapted way of developing is the use of single repos for everything from projects to teams. 'The industry has moved to the polyrepo way of doing things for one big reason: team autonomy. Teams want to make their own decisions about what libraries they'll use, when they'll deploy their apps or libraries, and who can contribute to or use their code.' Nrwl.

Advantages of using monorepos

• Standardisation

When building using monorepos, everything is a library in a sense. Monorepos are able to support a large number of frameworks. It's the same as building with lego pieces. Same lego in Vue is the same in React or Angular. All lego pieces can be used independently and together therefore consistent. We have one repo which is easily manageable. It allows us to have everything including shared functions in one repo.

• Code Sharing

Having consistent tooling helps in preventing code duplication which leads to over-engineering .

• Accessibility

Having your code in one repo allows a level of transparency that can't be found in polyrepos. This makes it easier to identify bottlenecks and even save time in debugging and code reviews.

• Easy workspace analysis

It becomes easier to map out the whole project without having to add more and more tools and libraries that might break the project . This also helps in refactoring . Normally you'll find yourself moving code in different repositories which introduces risk but its monorepos you simply have to move code in between folders.

The advantages are endless but not every team can work with monorepos. Understanding your strengths and weaknesses as a team will help determine whether working with a monorepo is fit or not

For backend teams that work with micro-service architectures

'You should update microservices independently, but you may think this is impossible with a monorepo. Meet this challenge by replacing rolling updates with more advanced deployment strategies, like blue-green or canary. You can deploy the new version side by side with the previous version while you ensure the new microservice version works as expected. If you detect a bug, you can quickly redirect traffic to the previous version.

Automated continuous integration and continuous deployment (CI/CD) pipelines help with all those monorepo challenges. Each development team can independently work the microservice, build its container image, and deploy it without affecting other teams. They can validate the microservice in a test environment before sending it into production, and keep both the old and new versions available. Containerization lets you deploy and test microservices independently without worrying about their different tools and programming languages.

CI/CD tools can scale automatically and help you manage complex deployments so that you can build, test, and even deploy individual microservices from within a larger monorepo.'

Ron Powell

Having well defined relationships helps teams mitigate the few disadvantages of monorepos thus reducing the burden of security , quality control and maintenance as refactoring is carried out.

If you find monorepos fit for your team or projects, you can try out a few such as :

• [NX] (nx.dev)
• [Turborepo] (turborepo.org)
• [RUSH] (rushjs.io)