Define the Relationship with Monorepos

My name is Philip Fulcher. I've got about five minutes to talk to you about monorepos. And so let's talk about it. But what do we talk about when we talk about monorepos? What even is a monorepo? And some people might say, oh, that's like when Google only has one repo for the entire company, right? And that's not what we're talking about. That is a scale of monorepo that is unfeasible for most people. You're probably not Google.

Maybe a monorepo is when you just throw all your code into one repo and then you figure it out later. And that's definitely not something that we want to do. That's going to run into all kinds of problems. So let's have a nice workable definition of a monorepo is a single repository containing multiple distinct projects with well-defined relationships. And what I really want to talk to you today is about this last element. What do we mean by well-defined relationships?

Let's think about relationships in code in terms of distance. So the closest that two pieces of your code can be related are just code that's in different files. You have a button component. It's got all your Tailwind classes that make you on-brand. And then you're going to import that button into your form to actually be able to use it. And so now there's a dependency between the form and the button. The form doesn't work without the button. And we do this all the time. And we kind of take for granted how great this relationship works for us. When you make a change in the button file, you can immediately see the change in the form. You have either a render in the browser, or you have a compilation error. Maybe you have a test suite running. That's going to tell you that there's a problem, or even lint errors. But you can understand the impact of your change immediately. And because of that, iteration is really fast. You make a change. You can see it. You can respond to it, fix it, move on to the next thing. But you're moving fast.

Let's see what happens if we take that relationship sort of one step away. And think about code in packages. And if we import that button from a design system that's published by our organization, this feels really similar to what we just did. Unfortunately, we've increased the distance between these two pieces of code. And what that does is makes understanding the impact of the change slow. To make a change to the button, I make a change within the design system. I have to go through some sort of compilation or bundling process, and then publishing, and then I have to consume the latest version of the package to see the final change in my form. And that's really slow, even when you're working by yourself on a single machine.

When we talk about crossing team barriers there, your design system team has to make the change, merge, cut a release, publish. You have to consume the latest version. That is a really slow understanding of the impact of the change from the design system team. And therefore, iteration is so slow. Let's take an even further step away in terms of relationship between codes and think about APIs. Your front end has an implicit dependency on your back end. It won't function without the back end in most cases. And so if you have an API that's developed, it's hey, we all agreed at the beginning of the sprint this API endpoint was going to be called Contact Create, right? Well, it came out as Contact Init. I don't know if you've ever had changes to your back end API happen like that mid-sprint. But now this relationship is even slower than we've talked about before.

Monorepos, when you put those multiple projects all together in a single repository, are going to reduce the distance of your relationships. That change that you want to make in your button or your back end API is now co-located with the front end code that's going to consume it. And that just means that it's in the same repo, and that we can import it, and we can use all the really nice tools that help us understand the impact of that change. And with some helpful tooling from a monorepo tool, we can understand those relationships and actually trace them to determine what's been affected by our changes. So when we talk about putting all of your projects or many, many projects into a single monorepo, we feel like we're making a huge change. But we're not actually changing the relationships between the projects that we already have. What we're doing is making them explicit. We're making sure that we know that that relationship exists and how we understand the impact of changes through that relationship. And by that, those relationships are well-defined. And through that, monorepos are going to help you move faster. If you want to learn more about monorepos, please visit monorepo.tools. It's going to help you understand the monorepo concept as well as many of the tools that are available in the space. I happen to think that the best tool for you to manage your monorepo today is NX. If you're here in person, you can come talk to us at the booth. If you're online, please visit nx.dev for more information. Thank you very much.