monorepo
I want to learn more about monorepos after learning about version control systems.
References
Notes
In version-control systems, a monorepo (monomeaningsingleandrepobeing short forrepository) 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, when it was commonly called a shared codebase.
A related concept is a monolithic application, but whereas a monolith combines its sub-projects into one large project, a monorepo may contain multiple independent projects.
Advantages
There are a number of potential advantages to a monorepo over individual repositories:
- Ease of code reuse
- Similar function or communication protocols can be abstracted into shared libraries and directly included by projects, without the need of a dependency package manager
- Simplified dependency management
- In a multiple repository environment where multiple projects depend on a third-party dependency, that dependency might be downloaded or built multiple times. In a monorepo the build can be easily optimized, as referenced dependencies all exist in the same codebase.
- Atomic commits
- When projects that work together are contained in separate repositories releases need to sync which versions of one project work with the other. And in large enough projects, managing compatible versions between dependencies can become dependency hell.
- Large-scale code refactoring
- Since developers have access to the entire project, refactors can ensure that every piece of the project continues to function after a refactor.
- Collaboration across teams
- In a monorepo that uses source dependencies (dependencies that are compiled from source), teams can improve projects being worked on by other teams. This leads to flexible code ownership.
Limitations and Disadvantages
- Loss of version information
- Although not required, some monorepo builds use one version number across all projects in the repository. This leads to a loss of per-project semantic versioning.
- Lack of per-project access control
- With split repositories, access to a repository can be granted based upon need. A monorepo allows read access to all software in the project, possibly presenting new security issues.
- More storage needed by default
- With split repositories, you fetch only the project you are interested in by default, With a monorepo, you check out (think Git) all projects by default.
Scalability Challenges
Companies with large projects have come across hurdles with monorepos, specifically concerning build tools and version control systems.
- Scaling Version Control Software
- Companies using or switch to existing version control software found that software could not efficiently handle the amount of data required for a large monorepo.
- Scaling Build Software
- Few build tools work well in a monorepo.
Comments
You have to be logged in to add a comment
User Comments
There are currently no comments for this article.