Understanding monorepos

What is a monorepo?

A monorepo is a code repository that contains the source code for multiple applications and packages.

There are more complex definitions that you can find out there but we're going to keep it simple. In a monorepo, you'll create organizational structures for your code where you can share "packages" to many applications. By bringing all of our code together, we give ourselves many opportunities for improved developer experience (DX), shipping velocity, and, because of that, better applications.

Improved discoverability

References to source code will always be a quick Search or Go To Definition away rather than spread across various repositories. This lets you work faster, ship sooner, and have better clarity about what you're shipping.

One "state of the world"

When you're working in a polyrepo, you may have many different versions of the source code that make up your applications. Your CI/CD process becomes more complicated as you have to manage the orchestration of packages against each other, creating potential for edge cases and other unexpected difficulties.

But, in a monorepo, we can guarantee that changes are atomic and that we know exactly what source code we are deploying. This simplicity lets us ship faster as we iterate over our applications and allows teams to work together much more quickly.

Faster than speed metal

Building your applications takes time as your source code is compiled and/or bundled for delivery to users. As you continue iterating on your application, you'll end up compiling the same packages over and over again every time you need to redeploy.

NOPE! Today's monorepo tools are built for making your workflow fast by never doing the same work twice. We'll create repositories that can get tasks done in milliseconds if the task has been done before.

A monorepo is not a monolith app

A quick mental note: The various applications in your monorepo can (and should!) act independently of each other. For example, making changes to your web application doesn't have to (and shouldn't!) force your mobile application to redeploy.

In fact, one of your applications may be a monolith. In the case of Next.js, you can create a frontend and backend in the same application (a monolith!)

This application would deploy itself monolithically - but that doesn't make your whole monorepo into a monolith! You could just as easily create a Node.js backend to use with a Vite frontend. These two decoupled apps can work together when deployed. You could easily make edits to any one of your three apps without redeploying another.

Maestros know how to build monorepos that do the least work possible on every commit to the repository. We'll learn how to isolate the pieces of our repository so that the workflows required to create deployments are high tempo, even at scale.

When to use a monorepo

As mentioned on the Motivation page for this resource, we're seeing monorepos are consistently proving their worth at all scales in today's software landscape. For that reason, you should think of a monorepo as your default and move away from a monorepo when it doesn't make sense.

Ready to make some music?

Head over to "The basics".