29, Oct 2022 ~ 6 min read

Universal Monorepos

Truly understand how easy it is to use the monorepo project structure.

Image by Brigad Engineering React Native Monorepos

Listen to something with me 😍

Colorize Klur - Entangled (Ole-Bjørn Talstad Rework)

Want to listen somewhere else? 🎧

Us JavaScript Developers
What is a monorepo?
Disadvantages to using monorepos
Advantages to using monorepos
Conclusion
References

Us JavaScript Developers

Have you ever found yourself thinking, “how can I easily build my project?” Where you have to use something on the frontend, backend, database or even a mobile app? Well, if using mostly JavaScript for development just like me you might think… well I’ll just use what I know best and you end up with something like this

Choose JavaScript, @frontenddude

Well if you’re in that type of predicament, in this article I will go over why you might consider using a monorepo setup to accelerate your development speed. But what is a monorepo?

Top

What is a monorepo?

In version-control systems, a monorepo (“mono” meaning ‘single’ and “repo” being short for ‘repository’) is a software-development strategy in which the code for a number of projects is stored in the same repository. This practice dates back to at least the early 2000s… wikipedia

A monorepo is a manner of structuring your project inside one repository, as opposed to having multiple projects that are scattered across multiple repositories. Monorepos are not a one key fits all solution, it’s just a way of structuring your project. Projects structured in this manner have a several pros and cons. Let’s go over them.

Note: Monorepos are not monoliths, a monolith project is a project that has all the components of your project in one codebase. Where the application grows in complexity when ever there is an additional feature. Whereas a monorepo is concerned with having your project structured into smaller sub-projects each with their own codebase and sharing them across as shared libraries.

Top

Disadvantages to using monorepos

Before we go over the good side of using monorepos, I want to first shed light on the challenges of working with monorepos. Most of these I am going to refer to them from my perspective as a TypeScript/JavaScript developer.

Project Setup: Project setup in Javascript projects comes with a learning curve and that applies to monorepo projects as well. IMO, it’s even more challenging to setup a monorepo project structure. This comes down to understanding how NodeJS, Browsers and libraries behave and how they work with our code. When we’re just starting out, we might be overwhelmed when making all these considerations. I believe it’s better to understand concepts like these before dabbling in monorepos. Here are some of my articles on this topic
1. JavaScript Module Types
2. JavaScript and It’s many Runtime Environments
Bad Performance: I guess this is one of the annoying one, because there is going to a performance hit once you have all of your codebase, backend, frontend, libraries and any other application under a single repository. You might not notice it when you start out, but once you get to finalizing your project you’ll definitely see some slowness when using git, your IDE, searching through your code. But that might just be an annoying thing to deal with considering the benefits or monorepos.
Breaking Changes: Imagine you’re working on a project, a NodeJS, where you have multiple custom libraries you built. Assume you have all of these libraries are being shared through a npm. The best part about this workflow is you can deploy a working version of library and continue working on it making breaking changes and it wont affect your other codebase that is using that library unless you explicitly push a breaking change onto npm. Even assuming you pushed a breaking change to npm, if you have versioning properly handled you can still keep working without having to upgrade.

This situation is different when using monorepos, if you have a breaking change in one of the sub-projects inside your monorepo, you’re going to have to fix to move on. Everyone else who is working on the project is either going to have wait until the breaking change is fixed, or they’re going to help out.
Ownership: Ownership is also another issue, since everyone has access to all the sub-projects, you’ll not be able to stop people from making changes. Either everything or nothing, that’s kind of the workflow.

Top

Advantages to using monorepos

If you’re here, you’re at least willing to understand the advantages of a monorepo. Well, let me explain.

Everything is there: Monorepos give you one benefit and everything else is going to build up on that one benefit, and that is easier visibility. This means everyone has access to everything about the project. All your backend API codebase, frontend logic, custom libraries you’ve built maybe to share across multiple frontend applications… etc. This is the benefit of monorepos really, you can clone, build and serve and you’re set.
Better Collaboration: Collaboration as a consequence of visibility is much better, you’re team can make changes and instantly see what’s breaking, run unit tests across all of the codebase, you don’t have to get a call saying your changes just took down the whole, at least it’s possible to make that kind of feedback happen when you’re working on a monorepo.
Easier Standardization: Imagine you’re working on a javascript project, using nx (a monorepo management tool), eslint, prettier, jest, typescript. You can configure all of those tools once and each of your sub-project can follow or make changes by overriding specific rules/properties. Imagine your backend, web app and mobile app having the same column width. Yhea, you don’t have to be angry when some other team is using 120 and you religiously prefer 80 column width… didn’t think that was possible too…
Deployment: When deploying a monorepo project, everything is included within one directory. All the information, dependencies and configuration. For those reasons the deployment process is clear, compared to how a multirepo project handles deploying a system.
Easier to Refactor: Refactoring & making changes across multiple is as simple as it can get.

Top

Conclusion

There is a fascinating article form Microsoft on Using monorepos during early in a project, It actually points out the benefits of monorepos is to accelerate a projects development which is very important during development phases of a project. I believe this where monorepos shine… they provide flexibility, freedom and speed for teams.