Thoughts about monorepos and code-sharing

norato profile image Felipe Norato Lacerda ・3 min read

Some weeks ago I went to a conference and I could hear more about monorepos and it makes my mind blows. The point that makes my mind blows was how to share code between applications in an easy way.

The problem

I worked on some projects that I really want to solve the code-sharing problems across frontend, libs, and microservices.

In a project, we had an Angular Web Application and many Node Microservices, each in different repositories. And it was close to impossible to share code between those applications since we did not have a private npm.

In other, we had to create an Angular Web application and an Electron desktop with Angular application both using an Angular Component Library. All in the same repository, and it as really difficult to manage, but, here we could share code.

For those projects, I think using monorepo could solve this kind of problems because we would have all applications in a single repository and we could painlessly share code.

But, the second project example we had a monorepo and it still causing pain to manage the projects. That was because we did not use a monorepo manager, we actually we did not know that it as a monorepo.

A possible solution

So, what really solves the complexity around managing multiples projects in a single repository is a monorepo manager. I have been trying nx by nwrl since that.

The NX has some commands to create, build, test and check the interdependencies between the applications and libs. It is really useful and it will keep all organized without multiple customs commands, as we need to make in the second project.

In this time studying and trying NX to manage monorepos I can list some pros and cons to use that for a javascript monorepo.


  • You don't need to download tons of node modules for each project. It will be reused by all libs and applications;

  • All code will be in the same place, so it is easy to navigate through the project;

  • You don't need to duplicate or publish some code in npm to share code through the application. It makes easy to refactor and improve code;

  • In a private project, you only need to allow access to a single repository;

  • Using a monorepo manager, like NX, you can use many commands from its CLI to automate the flow;

  • You will keep all working in the same branch;

  • It is easy to test everything together and check what artifact was affected by a change. You also can only test and build the affected artifact;

  • It is easy to create new applications. Is easy because we can use the CLI to create it and all provisioning and libs could be reused, it will save lots of time.


  • An untested change could break all project, in the same context that is easy to improve is easy to break everything;

  • You could not deny access to an application to a developer because you are keeping everything together in a single repository;

  • Is not so easy to create CI/CD to deploy a specific artifact. This is a point that I am still working to find a simple solution.


I suggest to test it a new project to check if this alternative will fit your needs. It could prevent that effect POC to production! Some questions you could ask yourself to decide to move to a monorepo:

1 - Do you need to share code between projects?
2 - Do you have more applications using the same environment/language?
3 - Do you can allow all developers to access all source code?
5 - Do you think about to create new projects that need to reuse some existent code?
4 - And the most important, do you really think that could help you to deliver faster?

That questions I ask myself when I decided to try to use monorepo. I am working on a huge frontend application and we are going to create more projects. We started to think about speedup our delivery and reuse many features that we created in the other one. So this migration is motivated to anticipate to be productive when new projects arrive.

And you?
Do you already test monorepo? What is your experience on that?

Posted on by:

norato profile

Felipe Norato Lacerda


A person who likes to solve people’s lives using Code and sometimes play Guitar


markdown guide

Hello Felipe!

First of all, great article! This is a important topic that a lot of companies are facing right now!

I just wanted to discuss a bit of the cos you pointed:

  1. You said it is easier to break things, well I don't think so, monorepo will expose much easier and faster if you broke anything, which is good, but not make it break more than normal. You will always need to have strong automated test suits if you wanna keep your sanity with big projects, no matter if they are in a monorepo or not.

  2. You said we can not deny access to specific developers because we are keeping everything in a single repository, but it is not true. Much of the git providers have some sort of tool to deal with it, like GitHub that has Code Owners:

  3. Nx gives you a bunch of commands that tests and builds only the affected apps and libs by that pull request, it can give you even a visual graph, and you can programmatic deploy those affected projects. Honestly, looks like you just lose one of the main tools that Nx have for monorepos:

That said, I am not saying that there is no cons when dealing with monorepos, but they are not those ones.

Once again, congratulations on the article, it is not because I am pointing somethings that it is bad man! 😁