This content originally appeared on Bits and Pieces - Medium and was authored by Ashan Fernando
Monorepos are still a go-to option for many code bases, and several misconceptions limit their potential.
Monorepo (Mono + Repo) is the approach in which we track the code of multiple projects in one repository. Since the code base is organized based on the directory structure, sharing dependencies across projects is straightforward.
Yet, several challenges come with Monorepos that you need proper tools to overcome. For instance, you may need to use Build Systems, which can understand the contexts of projects and their dependencies.
Monorepo: Why Classical Build Systems Fail?
This also leads to many misconceptions that prevent users from adopting Monorepos. Let’s look at several popular ones to distinguish between the limitations and misconceptions.
1. Monorepos Are Hard to Scale
Scaling is one of the biggest concerns when using Monorepos. As a codebase grows, the fear of unmanageable and slow repositories looms.
Instead of speculation, the most crucial part is to understand the limits and see how far these limits are from your monorepo. Most of these limits may depend on the platform (e.g., GitHub) and the source control technology (e.g., Git) you use.
To better understand, let’s look at several limitations posted on GitHub.
- Repository Size Limit: GitHub recommends keeping repositories under 1 GB for optimal performance and strongly suggests staying below 5 GB. A GitHub repository's hard limit is generally considered 100 GB.
- Individual File Size Limit: The maximum size for any single file in a repository is 100 MB. If you try to push a file larger than this, GitHub will block the push. Additionally, GitHub will warn you if you attempt to push files larger than 50 MB.
- Git Large File Storage (LFS): GitHub recommends using Git LFS to manage large files. With Git LFS, the file size limit increases to 2 GB per file for most plans, though it can be higher (up to 5 GB) for enterprise plans.
Most of these limits are set to keep Git working with optimal performance. And if you consider the numbers, a code base of 100 GB is huge (assuming large binary files are outside Git or in Git LFS) and typically comprises millions of files. Only a few companies in the world may have reached that milestone.
There are many techniques to optimize large Git repositories to reduce the size-performance impact, so you can even go beyond these limits by hosting Git on your own.
You can also follow architectural best practices like composable software development so that if the day comes, you can move away from monorepos with minimal friction.
2. Monorepos Are Just for Large Companies
When discussing monorepos, you may have heard tech giants like Google or Facebook still use them in practice. It’s easy to believe that only these massive organizations can benefit from a monorepo as they can build the necessary tools to overcome the limitations.
However, imagine a small startup that has several interconnected projects. They may find managing multiple repositories increasingly cumbersome as developers have to switch between repositories and implement strategies to reuse code between projects.
Switching to a monorepo transforms their workflow, centralizing their code and simplifying dependencies. Even small teams can experience enhanced collaboration and streamlined processes. Therefore, monorepos aren’t just for big players. You can find the right tools and build code bases for effective collaboration.
3. Monorepos Lead to Long Build Times
The myth that monorepos lead to long build times stems from the assumption that every change triggers a complete rebuild. We usually store multiple projects in the monorepo, each with a different life cycle. The challenge comes when shared dependencies get modified.
Suppose a shared dependency of all the applications has a critical security vulnerability. Once it gets fixed, all the projects need to be built and released. And this is where we need to consider how frequently this can happen. And in reality, this is not something that frequent.
Besides, you can make these shared dependencies as components or packages so that they are versioned and projects do not directly refer to them via code. This allows different applications in the monorepo to use the version of choice.
Therefore, a proper setup can enhance build efficiency, debunking the misconception that monorepos leads to longer build times.
4. Monorepos Make Dependency Management Complicated
When using monorepos, one of the main challenges developers face is the lack of visualization of dependencies by just looking at the code base’s file and directory structure.
If you use multiple repositories, the dependency structure becomes explicit if you break dependencies into different repositories. Yet, it's not practical to manage repositories for each dependency or dependency group since it significantly increases the time for integration tests. In contrast, if the code is in a monorepo, you can directly modify and check its dependencies.
Therefore, to compare its complexity, you must weigh the different aspects of dependency management between monorepos and multiple repositories.
Besides, you can use platforms like Bit to detect dependency changes, which keeps track of the dependency graph and significantly reduces the overall complexity of dependency management, regardless of the repository structure.
Therefore, the challenge of dependency management isn’t monorepo-specific and needs to be addressed using the proper set of build and dependency management platforms.
5. Monorepos Increase Merge Conflicts
When multiple developers work on the same code base, merge conflicts will likely occur. But it's essential to understand the context here.
In a monorepo, each development team may own specific projects. And, in a large organization, even the shared dependencies may be handled by a platform team that owns them. So, the likelihood of getting merge conflicts is still bound within sub-teams, which happens irrespective of the repository structure.
Therefore, using a monorepo with a proper governance structure can avoid any merge conflicts across teams.
Conclusion
Monorepos offer numerous advantages, from simplified dependency management to improved collaboration and transparency.
With the right tools and practices, monorepos can effectively manage multiple projects within a single repository, regardless of company size or project complexity.
Learn More
- 11 Great Tools for a Monorepo in 2021
- Monorepo vs Polyrepo: 5 Things You Should Consider
- 5 Common Problems with MonoRepos and How to Fix Them
- Solving the Stress of Monorepo Management with Bit
5 Misconceptions About Monorepos was originally published in Bits and Pieces on Medium, where people are continuing the conversation by highlighting and responding to this story.
This content originally appeared on Bits and Pieces - Medium and was authored by Ashan Fernando
Ashan Fernando | Sciencx (2024-08-26T12:36:04+00:00) 5 Misconceptions About Monorepos. Retrieved from https://www.scien.cx/2024/08/26/5-misconceptions-about-monorepos/
Please log in to upload a file.
There are no updates yet.
Click the Upload button above to add an update.