Skip to main content

How many repositories do you need?

A common misconception about Nx is that it will force us to regroup everything into a single monorepo. As mentioned before in Why Nx?, while Nx excels at managing monorepos, it offers many benefits even for repositories containing a single application maintained by a single developer.

You can apply Nx to each repository independently, and then mix and match by merging repositories and grouping them into one or multiple monorepos.

Here is a visual example of highly aligned teams sharing an "Ecommerce Monorepo" where some of their libraries are published to a registry, allowing other teams to use them in their own repositories or monorepos.

Monorepo Grouping Strategy​

The grouping strategy will mainly depend on the social structure of your company. Interestingly, Conway's Law applies quite well here:

Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure.

Indeed, monorepos require some rigor. Different teams with different goals, visions, and engineering cultures may not be able to work together in a monorepo. For example, sharing a monorepo between two teams:

  • one with a Continuous Deployment culture and a strong testing strategy,
  • and one that has a monthly release cycle relying mostly on manual testing,

will likely result in chaos or frustration for at least one of the two teams, if not both.

Monorepo Grouping Prerequisites​

Here are some prerequisites for grouping repositories into a monorepo:

  • Engineering Culture Alignment: Teams should have a similar engineering culture (e.g. quality expectations, collective ownership, openness, knowledge sharing, ...). In other words, teams should be able to work together in a monorepo without being frustrated by the practices of other teams. Monorepos won't magically solve cultural issues; you should address cultural issues first.

  • Strong Conventions: Teams should agree on a common set of rules and conventions.

  • Strong (automated) Testing Strategy: The testing strategy should instill enough confidence in all teams. If a single team lacks confidence in their tests, it may slow down the progress of other teams.

  • Automation: In addition to tests, teams should be prepared to rely on automation in general. You will often use migration scripts to keep the monorepo up-to-date with the latest tooling.

  • Confidentiality Awareness: Using Git, it is not possible to restrict read access per folder (i.e. per app or lib). If a team is working on a project with a different confidentiality level, you might want to keep it in a separate repository.

  • [OPTIONAL] Adhering to Single Version Policy: Surprisingly, agreeing on a single version for each dependency used in the monorepo can make the code cheaper and easier to maintain, while keeping it up-to-date, secure, and less error-prone.

This list is inspirational and not meant to be exhaustive.