Thoughts about monorepos and code-sharing

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.

Pros

• 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.

Cons

• 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.

Considerations

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?