What is a monorepo ?
A monorepo is a code repository that holds multiple applications. These applications can be related or completely independent. It also allows us to share code among these applications without using any kind of package manager. It should be noted that a monorepo is not a monolith. A monolith is huge amount of coupled code of a single application in a single repository.
One source of truth: Instead of having multiple repositories we have a single repository with all the code and configurations to manage it.
Consistent dependency management: Code is shared in a monorepo, so are our dependencies, that means all your applications will have the same versions of the libraries they need. There are no versioning conflicts or dependency hell.
Consistent coding practices: Enforcing code quality standards and a unified style is easier when you have all your code in one place. For example, having a single configuration for all dev tools like code linters, code formatters, testing configuration etc.
Visibility: The entire code is visible to everyone. This enables cross team collaboration.
Code reuse: The same repository houses common modules, shared libraries, and helper utilities as local packages. These local packages are simple to maintain. we don't need to publish them to private npm repositories, all the applications are always running the most recent version of these local packages.
Adding a new project/application: It becomes extremely easy to add a new project to the repository since all the dependencies, utilities, CI/CD, Git, and test runners are already included.
Breaking changes are easy to tackle: Breaking changes in shared packages/dependencies are communicated immediately. .
Unified CI/CD: For each application, You can use the same CI/CD and deployment process.
Unified build process: We can have a single build process to build all the applications, thus increasing the consistency of the final builds.
Poor git performance: When monorepo reaches tens of thousands of files, and extremely huge number of commits git performance gets impacted.
Broken master: If for some reason, your master/main branch is broken, all the projects might be impacted.
Learning curve: For people new to the codebase, it has a learning curve since the codebase is a little intimidating.
Ownership: Code ownership becomes difficult because anyone can come and edit your code.
Code reviews: Code reviews may become a little difficult if changes are made across multiple packages at once.
Testing: This isn't actually a disadvantage. However, you must ensure that your reusable packages are thoroughly tested and that automated testing is in place.
Unable to restrict access: Every member who has access to the repository will have access to all the applications. There’s no way to restrict some applications, which is irrelevant to the developer.
Our web team builds a wide range of applications, including internal projects, client-facing applications, webviews for our native applications, marketing pages, and other web experiments etc. Most of these applications are built with modern frontend frameworks/libraries such as ReactJs.
Building multiple applications with modern dev tools comes with its own set of requirements:
It is evident from the preceding statements that managing a large number of applications in a fast-paced startup is a repetitive and a tedious job. In addition, each project contains a lot of boilerplate code. With monorepo, we could entirely eliminate all development dependencies and concentrate just on the application and business logic.
Roughly in February 2019, we started an ambitious web project called Athena. Which aimed to solve all the above problems by creating a unified codebase for future web projects. Back in 2019, the only tool that could manage workspaces was Lerna and yarn Workspaces
We started our monorepo with Lerna because it had all of the capabilities we needed. For approximately two years, everything was well, however lerna had some active maintenance concerns. We opted to step away from the project because there was no active development going on. Currently, our repository uses Yarn workspaces, which allows us to embrace any new tool in the future without requiring a larger migration strategy.
Monorepo has received a lot of attention recently. Plenty of new tools have been created to help with monorepo design patterns. We'd definitely try out a few of these tools to see how they could help us manage such a large repository better. Some of the tools worth considering are :
Monorepo design is simply another approach to application development. It may not be the best way to build or design applications for your specific use case, but it has greatly simplified the lives of our developers. If you find yourself in a situation where you need to build multiple applications, you should definitely consider monorepos.