When it comes to monorepos and polyrepos, there are many misconceptions. These misconceptions can cause confusion when it comes to knowing whether one should be preferred over the other.

In this article, I will introduce both and will help you to differentiate them with detailed insight for better decision-making.

Monorepo in a nutshell

A monorepo is a single repository for one or more projects. For example, you might store your frontend code and backend code in two different folders in the same repository. Besides, a single monorepo can contain both related and independent projects.

There are several advantages when using a monorepo including:

• Easy to share code between projects.
• Maintain test suites, automation scripts, infrastructure configurations in one place.

Large-scale companies like Google, Facebook, and Microsoft use monorepos to maintain their projects.

But, one of the common misconceptions among developers is that a monorepo increases coupling in application code. It is not true, since ultimately the monorepo is responsible for source control, not application dependencies.

Polyrepo in a nutshell

Polyrepos are the opposite of monorepos. When a team adopts a polyrepos, they try to identify different projects, components, and dependencies before splitting them into multiple repositories.

There are several advantages when working with polyrepos:

• Helps to manage access control separately for different code bases.
• Less number of conflicts when ‘checking in’ code.
• Fewer changes to ‘pull’ if you work with several repositories.

Besides, when using some DevOps tools, it becomes easy to build and publish unless they explicitly support monorepos.

Let’s take a look at the factors you should consider before choosing one over the other.

Choosing Between Monorepo or Polyrepo

1. Dependency Management

A monorepo simplifies the management of shared dependencies. For example, when you first start a project, you will most likely be developing the shared code inside a folder, and the shared code gets updated regularly. In a Monorepo, the main advantage is that each component receives the latest version of the shared code. The downside, however, is that the impacted areas are high and require thorough testing. Nowadays, open source software such as Bit vastly improves the developer experience for managing shared dependencies. What used to be tedious can now be managed from a single workspace.

In contrast, polyrepos requires you to either publish your shared code as a library or use something like git-submodule or git-subtree. Therefore, it requires better governance for shared code since different versions are used across projects.

2. Collaboration

Monorepos enable better visibility and collaboration across teams, naturally encouraging code reuse. The ability to standardize code and tooling across teams is another benefit. For example, you can impose branch policies to keep your main branch clean, limit access to specific branches, enforce naming guidelines, include code reviewers, and enforce best practices that cut across your teams. Therefore, for teams, that work closely and transparently, Monorepos helps to boost productivity.

However, if you work with remote teams or have outside collaborators, giving fine-grained access control can be a challenge. Either you must grant access to the entire codebase, or none.

3. DevOps

Suppose you need to release all of your components at once. In that case, a monorepo can simplify DevOps, as a single repository helps to build the entire codebase at once.

However, modern software architectures, such as like microservices and microfrontends, reduce the need for big bang releases. Therefore, with monorepos, you can manage the lifecycle of components independently regardless of repository structure.

One challenge with monorepos is for continuous integration to detect changes on specific paths. Fortunately, new tools support path-based build triggers to avoid this challenge.

4. Tech Stack and Size

Monorepos typically push towards using a compatible tech stack. As a result, incremental adoption of new technologies can be a challenge. Still, it’s not impossible, as we are used to storing both frontend and backend in a single repository.

Furthermore, getting started with such a large codebase in a monorepo is difficult. There is no clear separation between applications, and new developers would have a large scope to learn. If you don’t manage to decouple your code, it also makes it costly to modify for improvements.

5. Refactoring

Monorepos enable atomic commits and greatly simplify large-scale refactoring. In a single commit, developers can update multiple packages or projects.

In a polyrepo, developers must make Pull Requests for each repo and figure out which order to build the changes, whereas, in a Monorepo, you only need to make an atomic Pull Request that contains all commits related to the feature that you are working on.

The codebase will be organized in a single tree in a Monorepo so that developers can easily trace dependencies.

If your team prefers the ability to make atomic commits, you should go with Monorepos.