Monorepos versus Polyrepos for Microfrontends

Since the time engineers at Google and Facebook mentioned they have a single monorepo in their organization, the developer community – especially the frontend community – has been actively participating in debates and discussions on monorepos versus polyrepos.

We are seeing more and more teams leaning more toward monorepos for maintaining their frontend code. However, which should you choose between a polyrepo and a monorepo based on what the community thinks?

As we will learn in this chapter, the decision to go with a monorepo or a polyrepo is far deeper than just fancy technology or hype. We will see that, in fact, it is more to do with teams, and the culture we would like to establish within teams.

In this chapter, we start by understanding what polyrepos and monorepos are. We will see how each of them impacts how teams work and collaborate, then we will see why monorepos are more suited for microfrontends. Finally...

Technical requirements

As we go through the code examples in this chapter, we will need the following:

• A PC, Mac, or Linux desktop or laptop with at least 8 GB of RAM (16 GB preferred)
• An Intel chipset i5+, AMD, or Mac M1 + chipset
• At least 256 GB of free hard disk storage

You will also need the following software installed on your computer:

• Node.js version 16+ (use nvm to manage different versions of Node.js if you have to)
• Terminal: iTerm2 with Oh My Zsh (you will thank me later)
• IDE: We strongly recommend VS Code as we will be making use of some of the plugins that come with VS Code for an improved developer experience
• npm, yarn, or pnpm – we recommend pnpm because it’s fast and storage-efficient
• Browser: Chrome, Microsoft Edge, Brave, or Firefox (I use Firefox)

The code files for this chapter can be found here: https://github.com/PacktPublishing/Building-Micro-Frontends-with-React

We also assume you have a basic...

Repo types and their nuances

In this section, we will learn exactly what a polyrepo and a monorepo are.

As most of you will already know by now, repo is short for repository and refers to storage for all the files for your project. It also keeps track of all the changes to those files. This means, at any time, we can easily go and see what lines of code were changed, by whom, and when. In most cases, we use Git for version control. Some teams may use other systems, such as Mercurial or some other distributed version control system.

There are two strategies that teams most commonly use for managing repos. They are commonly known as monorepos and polyrepos. There are other patterns, such as Git submodules or Git subtrees, but these are beyond the scope of this chapter. We will focus on monorepos and polyrepos.

Monorepos

As the name suggests, mono means single and so the source code is managed in a single Git repo. This means that all team members work on a common single repository...

Choosing Monorepos for Microfrontends

After going through the pros and cons of polyrepos and monorepos, which one would you choose to use for your project? Well, you can choose either one of them and build microfrontends. Like all things in programming, there are trade-offs for every decision you make, and you need to be clear about what trade-offs you are comfortable with.

For the rest of this book, we will choose to go with the monorepo setup for the following reasons:

• With monorepos, team members are naturally encouraged to collaborate by learning and reviewing each other’s code.
• It allows all teams to easily use a shared library of components. This ensures that each micro-app built as part of the overall app has the same look and feel and the overall user experience is consistent as the user interacts with the different micro-apps.
• It also makes it easy for central platform teams, such as the DevOps team or admin team, to easily refactor code across all...

Setting up our Monorepo

In this section, we are going to set up our monorepo, which will act as a base for our microfrontend apps. We will learn how to set up the right permissions and the necessary quality gates. Along the way, we will also learn about a couple of productivity tricks and plugins that improve the developer experience.

For this example and the rest of the chapters, we will use Nx as the monorepo to build our microfrontends as it allows you to build both a package-setup-style and an integrated-style monorepo. You can equally choose either Lerna or Turborepo to build your microfrontends.

Follow along with the step-by-step guide to set up an Nx monorepo:

1. Open up the terminal, cd into the folder where you generally keep your projects, and run the following command:

   pnpx create-nx-workspace@14

   The preceding command will install a couple of libraries and will then prompt you for the name of the workspace (e.g., org name). This will be the name of the folder within...

Summary

With this, we come to the end of this chapter, where we unpacked quite a bit. We saw how teams today are choosing between a monorepo and a polyrepo approach to version control their code bases.

We then went into the details of how the choice of a polyrepo or a monorepo impacts how your teams operate, how easy or difficult it is to refactor code, and who owns the responsibility of fixing breaking changes in the repo.

We then saw why choosing monorepos for microfrontends has more benefits, such as the ease of managing all the micro-apps within a single repo, especially when it comes to running multiple apps locally and managing the tooling centrally for all the apps within the monorepo.

Finally, we went about setting up our monorepo, where we saw the benefits of using a tool such as Nx, which provides us with prebaked quality gates such as ESLint and Prettier to ensure consistency and code quality. We also saw how to use Nx Console to easily create new micro-apps and...