Understanding monorepos

When we think about building apps, we’re typically talking about one app, one git repo, and one build output. However, this one-app-one-repo setup is not always reflective of the real world experience of developers. Oftentimes, organizations will make use of a single repository with every app, component, library that could be used being developed there. This is a monorepo, and they’re starting to become very popular.

So what makes a monorepo so interesting for organizations? Why would they want to put all their code in one place and maintain what could be a massive git repo instead of having many small and separate repositories? Well we at Ionic have a lot of experience with monorepos and wanted to provide some guidance for how Ionic users could implement a monorepo setup for their teams. Let’s dive in.

What makes a repo mono?

So really, a monorepo is just a word for a git repo that contains multiple projects. As we hinted at in the beginning of this post, these projects could be multiple apps, shared libraries/services, shared components, etc. This way, there is one place for people to contribute code and consume it in their apps. A great example of where this could be helpful is in delivery service apps. There are two public apps, the buyer and the shopper, that serve different needs but make use of the same utilities. For example, there could be a shared component library that provides the items in a consistent design. There could be different services that are used to communicate with the backend that are needed in both apps.

Instead of having multiple implementations, it makes more sense to provide those utilities in a monorepo, where the apps can just make use of the same packages. The key term here is “packages”. What gets created in a monorepo is essentially multiple packages that can be consumed in an app. Much like how we import external packages from our node_modules, monorepos just move the location of those packages to the same place as the app.

Why is this better?

If we’re keeping all of our code in one project, how is this any better than splitting up our code and maintaining separate repositories?

By keeping all of our code in one repo, we keep all of our dependencies up to date across an organization. This is probably the biggest benefit of a monorepo. Now we’re no longer having to spend time updating dependencies across various different projects. Instead, we update things once at the root and we’re done, outside of making any needed code changes. If we do need to make code changes, we have access to the entire code base and can make those changes directly. If we need to make changes in different parts of the apps that we might not be familiar with, no problem. We can coordinate with the teams that are code owners there and make those changes.

Monorepos in this case can:

• Reduce the burden of maintaining dependencies (dependency hell anyone? )
• Simplify refactoring code across an organization
• Improve cross-team collaboration

Any way you paint it, monorepos are a big win for teams.

Monorepos in practice

Ok, so monorepos are great, now how do we implement them? Well, there are a lot of different ways to do this and each framework ecosystem has its own recommended approach that we do not have time to cover in this blog post. Thankfully, we’ll be covering the recommended way to implement monorepos in the frameworks we support (Angular, React, and Vue) in an upcoming blog series. By the end of this series, we hope that if you want to adopt a monorepo setup in your organization, you’ll have the tools you need!