Introduction

[00:00:00]
>> Mike North: Welcome to TypeScript Monorepos V2. I'm Mike North, I'm a principal staff engineer and product architect at Stripe and I've been a front end master's instructor for over ten years now. And today I wanna talk to you about monorepos. So first off, what is a monorepo? It is the concept of having a single git repository that contains multiple packages.

[00:00:23]
Sometimes companies will have like a language level monorepo, so Stripe is one of these. We have a monorepo for all of our Java code, all of our Ruby code is in a different repo, and then we have a big JavaScript monorepo as well. There are also open source projects like if you've used Babel before, there are many others where it's kind of one project, but if you look into it, you can see there are multiple distinct packages and you will find each of these packages on NPM and they'll each have a version.

[00:00:55]
Sometimes you're using just a couple of these things, not the entire contents of the repo in order to do something. What are the benefits of organizing your code this way? Why would you aim for a monorepo instead of the poly repo approach where you would treat every library you have as a separate git repo?

[00:01:13]
Well, first off, there's the issue of dependency management. If you've ever worked on something, say in the open source JavaScript ecosystem, you'll make a change in the library, you'll open up your PR and it'll get merged. And then you have a whole bunch of work where you have to go to other packages that depend on this and then run NPM install or PNPM install or whatever it is and float that lock file pinned version forward a little bit.

[00:01:43]
And you kind of have to pull it through all of the things that depend on it and this has to happen in multiple layers, right? You could be several layers deep in a dependency graph and a small change could result in you having to do a lot of work beyond making the code change just to propagate through a polyrepo ecosystem.

[00:02:03]
Well, the idea of monorepos is you're often locally referencing other parts of this software project and you're kind of evolving all packages at once. You could open up a single pull request that touches three or four different packages within one git repository, get that merged, and there's really no follow on step that you have to take.

[00:02:29]
So that's part of what makes it attractive, especially for a large company with a lot of different things going on a lot of different packages that they have set up. It's kind of attractive to say we don't have to deal with this problem of somebody made an improvement, but it's a whole new set of work to sort of propagate that improved, whatever it is, that chunk of value through our ecosystem.

[00:02:55]
And you end up with people that are sort of two, three years behind on some dependency just because they haven't gotten around to doing that work. A additional benefit of this, and it's possible to get this benefit in a polyrepo ecosystem, is it's that in a monorepo, it's generally easier to be able to say I've made a change in a library that's say three levels deep in a dependency graph.

[00:03:16]
Say it's some UI that depends on some library that depends on some other library that depends on some other library, and you're right there at the bottom. Well, it's a lot easier when everything's in one git repo to sort of run the entire test suite, not just for the library you changed, but everything that depends on it.

[00:03:35]
And ensure that you're not just validating against some small set of unit tests, you're validating the whole project when composed together, did this actually work? Am I going to be able to roll this.