The Case for Monorepos

[00:00:00]
>> Steve Kinney: We're going to call this under the idea of monorepos. A monorepo is kind of really the squishiest of all terms, right, which is the concept that you might have multiple small micros or all front ends, or you can have a big front end in a micro front end architecture, right? Why? Maybe they're all big, I don't know. More than one front end that happens to be in the same repo, right? Because when everything's a different repo, tooling's weird, right?

[00:00:36]
You gotta clone down the repo and put it all together. We can kind of deal with stuff when it's in the same repo. So monorepos can, again, as we saw in the very beginning of this workshop, have multiple packages, right? You know, you can have micro front ends in one repo, you can have micro front ends across many repos. I guess you can have a monolith spread across multiple repos. I mean, if you broke out your design system into your own repo and you're the only one using that design system, guess what you just did?

[00:01:05]
Like, you effectively made that pattern up. I say that as somebody who absolutely did it. The argument here, and this has always been my case, again, I believe my bias is just out there, is more repos, more problems, and more CI/CD chains to manage, more everything to deal with. I care not to do that if I can avoid it. That said, we all have more than one repo. The marketing site, the doc site, other special things.

[00:01:32]
Perhaps, again, your component system got broken out to its own because some other teams said they were going to use it and they never did, right? You can have more than one repo, I have more than one repo, we all have more than one repo, but like, you know, as many repos as you need and as few as you can get away with is my personal philosophy. But, you know, because all of a sudden I just need to find out that I misconfigured a package.json in one, and I don't want to do that four times, or build script in one, and I don't want to change it to four rebuilds personally.

[00:02:05]
I am lazy. So the case of when you have those boundaries like we talked about before, like if you have something that has multiple languages or has like a service worker section and a DOM section and a Node section that all need different TypeScript configs, you can either break it into their own repos, or you can figure out how to organize one repo, right? The monolith has failed you at this point, most likely, and you need to choose some kind of, you know, multi-component architecture at this point.

[00:02:33]
I'm going to try to make the case for a monorepo. If you hate this idea and want to break everything out into the other repo, well, we talked about that. So, you know, obviously, if you're saying it's like, well, team ownership, do you have to have your own repo to have autonomy? Is that actually a true statement? I don't think it is, especially if you're going to do that one build anyway. You've lost most of that to begin with, so like, who are we kidding?

[00:03:01]
Like, if you're going to do the multiple repos, you should go the module federation route. The second you're deviating from that, you might as well just move the simplicity to autonomy thing over to the monorepo. So now, instead of each team owning their own repo, they own a package inside the repo, which means sharing code is easy with the shenanigans we're talking about of like, well, you could push up a private npm package, and then everyone shares the npm token, but those are only good for 90 days.

[00:03:29]
You gotta make sure you rotate those and yada yada yada. You can just not deal with that because it's just like one directory over. Workspaces are a thing that exists for this express purpose. You're not jockeying stuff up to some other third thing, whether it's GitHub packages, a private npm repo, a private npm registry. You're just not doing any of that. And simplicity is good. Again, we talked about before when Rodrigo asked me that question of like, then how do you keep everything in sync?

[00:03:58]
Well, you can run one script across one repo with one pull request, trigger the builds on all the things, and be very clear that everything works, right? But you still get the autonomy where people aren't touching the same files over and over again on different teams. You can deploy all at once, right? That does not necessarily mean that you need to run all the tests all at once or even build all at once.

[00:04:25]
You can simply deploy one atomic commit, right? And we'll talk about this. I'll spoil the answer, which is, let's say you have six packages and you built them all and you stored a hash of the built assets, and then you have a file change and only one of those hashes changed. How many packages do you need to rebuild? Just the ones that changed, right? So you can have many, many, many of the advantages of why people split stuff out into multiple repos with a lot less of the complexity, right?

[00:05:00]
Like, and I think there's something to be said for that. And then finally, like type safety, right? Like, if I change the API, like let's say I run the design system and I change the props on the button, right? Your CI/CD is just going to pass just fine because you have the old outdated types, right? Even though it's going to break in production. In this case, at the very least, they're all together, right?

[00:05:27]
We'll all know if me changing something broke yours, or if you're behind and need to change something to deploy, right? We'll know all at once. There's like, yeah, it's not as flexible as separate repos and separate deploy pipelines. I would argue that's a virtue, right? But that's my philosophical belief. So we talked about pnpm workspaces, but we'll kind of dig into it a little bit more. Like, the ones that pnpm ships are just like kind of an enriched set of features of the one npm has, in the same way that like yarn and pnpm exist, because like they do stuff like caching when npm didn't.

[00:06:17]
It's like somebody got angry at npm one day and made their own package manager still posts from the same registry. They also have their own takes on workspaces. And so, following mostly the same protocol, they'll try to like hoist the dependencies. A question like npm does not do this, pnpm does, where we'll try to like resolve the dependencies as part of the build process to answer the question of like how do you keep all of them in sync in one of these repos.

[00:06:48]
Like, depending on the tool, they offer some more or less flexibility. Pnpm is the strictest, npm is the loosest, Bun lets you choose, great. What else? Yeah, so the advantages, what's missing. That whole what order do things need to get built in? Pnpm does not solve that for you. Npm doesn't solve, Bun does not solve that for you. The caching does not get solved, figuring out what changed and what didn't doesn't get solved, dependency graph visualization.

[00:07:15]
I always think that's cool when I'm looking in a library and I realized I've never ever used it outside of like the first week of using the library, because once it's working, I don't look at that.