Why we need Monorepo
These days, many tools can run “npm install” and “npm run build” in 20 different folders. But, not all tools can facilitate a proper monorepo.
Facilitating proper monorepo development means solving challenges like operating the test and build processes for decoupled modules, being able to independently publish modules from the project, and managing the partial impact of changes on every affected dependant module in the project.
Tools
- PNPM/Yarn Workspaces
- Nx
- Lerna (with Yarn worekspce)
There are many other tools doing this monorepo
Example like Lerna
This tool really helps while dealing with semantic versions, setting up building workflow, pushing your packages, etc. The main idea behind Lerna is that your project has a packages folder, which contains all of your isolated code parts. And besides packages, you have the main app, which for example can live in the src folder. Almost all operations in Lerna work via a simple rule — you iterate through all of your packages and do some actions over them, e.g., increase package version, update a dependency of all packages, build all packages, etc.
With Lerna, you have two options on how to use your packages:
-
Without pushing them to remote (NPM)
-
Pushing your packages to remote
While using the first approach, you are able to use local references for your packages and basically don’t really care about symlinks to resolve them.
Type caption for image (optional)
No way to restrict access only to some parts of the app. Unfortunately, you can’t share only the part of your monorepo — you will have to give access to the whole codebase, which might lead to some security issues.
Lerna with Yarn workspaces
Type caption for image (optional)
Lerna makes versioning and publishing packages to an NPM Org a painless experience by providing helpful utility commands for handling the execution of tasks across multiple packages.
Yarn Workspaces manages our dependencies. Rather than having multiple node_modules directories, it intelligently optimizes the installation of dependencies together and allows for the cross-linking of dependencies in a monorepo. Yarn Workspaces provide tools, like Lerna, the low-level primitives it needs to manage multi-package repositories.
Let’s talk about the pros and cons of Monorepo
The Git committee become heavy !!
Poor Git performance when working on large-scale projects. This issue starts to appear only on huge applications with more than a million commits and hundreds of devs doing their work simultaneously every day over the same repo. This becomes especially troublesome as Git uses a directed acyclic graph (DAG) to represent the history of a project. With a large number of commits, any command that walks the graph could become slow as the history deepens. Performance slows down as well because of the number of refs (i.e., branches or tags, solvable by removing refs you don’t need anymore) and amount of files tracked (as well as their weight, even though heavy files issue can be resolved using Git LFS).
Higher build time. Because you will have a lot of source code in one place, it will take way more time for your CI to run everything in order to approve every PR.
Pros of Mono Repo
The biggest advantage is we can symlink packages and use them locally and manage code separately
Like react app we can use reusable components in storybooks and storybooks can be a part of monorepo from there we can access components
- One source of truth — Instead of having a lot of repositories with their own configs, we can have a single configuration to manage all the projects, making it easier to manage.
- Code reuse — If there is a common code or a dependency that has to be used in different projects, we can actually share them easily.
- Transparency — It gives us visibility of code used in every project. We will be able to check all the code in a single place.
- Atomic changes — We can make a single change and reflect the changes in all the packages, thus making development much quicker.
Comments