At my new job I recently had to refactor several React JS projects to React Typescript. What struck me then was the considerable portion of duplicated code among several projects that had basically a common core: user authentication, custom settings for a well known UI library, components that were the same in every project, etc.

With the "recent" npm update I was becoming more and more interested in learning how and when to use monorepos so it seemed like the perfect fit for a test drive. With the Jira ticket opened, I started implementing a monorepo so that all these projects would seem a little less boilerplatey.

What is a monorepo?

Rather than just copy-pasting the textbook definition of a monorepo from Wikipedia, let me try to explain what I understood and gained from it with my own words.

The benefits of a monorepo

Aside code-splitting and separation of concerns, creating a monorepo will help newcomers better understand the code base since everything is accessible. You might enforce rules where a team should only modify a specific set of sub-projects but it will often help to get a grasp of a project when the code is really accessible.

The drawbacks of a monorepo

The main drawback that I encountered is that it makes a huge repo with loads and loads of code which might make it more difficult to setup CI/CD tools if you need granular pipelines for each sub project.

So, when to create a monorepo?

When not to create a monorepo

Not every project is suitable for a monorepo structure: oftentimes following the KISS (Keep It Simple S...) principle is your best go. But as soon as you're launching a project that you know is gonna be huge, and modular, monorepos are one of the best thing you can do to help structure your project. For example, let's say you're developing a simple web todo-list application (sticking with the basics here). Since there are not a ton of features to implement and split across several files, monorepos won't be your best bet.

When you should go for it

But then, add more features to this application, like markdown support, role-based authentication, sharing access to some parts of the app, etc. You're gonna need some additional developers/teams to develop everything before the inevitable deadline. In that case, having a monorepo set with interdependent sub-projects so that teams can focus on their specific business logic is a good go: regressions will be easy to see, the code splitting will be ideal and you reduce the risks of merge conflicts since the application itself should be a simple project while the other sub-projects will focus on the features and business logic.

---

This is the first article of a series.

In the following articles we will setup a Svelte components library and then use it in an example app.