Course Project Overview

[00:00:00]
>> Mike North: So in this course we're going to be working with a small project that is the minimum example, or close to the minimum example of a monorepo that has some layering and dependencies. So we're going to start with everything being together. It's a simple svelte app with a node server and some things that both the server and the UI need.

[00:00:24]
And we're going to factor it out into a monorepo. We're going to show how we can automatically link different packages within the monorepo. So you can just edit whatever you need to edit and those changes take effect immediately. You can just still treat this. You get the same benefits of the monolith despite it being broken up into a bunch of packages.

[00:00:49]
We're going to, towards the end of the course, get to this benefit of dependency aware task execution for build lint and testing. What that means is I touch a low level dependency. I want to run only those tests that could have potentially been affected by my changes. Not just the package that I touched, but the package I touched and anything that depends on it.

[00:01:18]
Let's run just those roles or, sorry, let's lint just that subset of packages. Or let's test just that subset of packages. We're going to explore the idea of monorepo packages like sometimes some packages are more coupled than others, where you might think of there being some sort of private API between packages, where sometimes things are just more intimately entangled in some cases than others.

[00:01:45]
And I'll give you some tools where you can deliberately create those boundaries and make sure that your TypeScript types are correct and helpful in cases where you deliberately want a lot of deep private access between packages. And then in other places you can say, hey, look, there's this sort of blessed surface for the package.

[00:02:10]
In the general case, you should only be integrating against these points. We'll also look at automatic code documentation as well. How can you have some nice generated docs that don't require a human to go in and keep updating things that explain all the packages in this monorepo project.

[00:02:33]
They're kept up to date automatically because they're derived from code comments and from the types themselves. So these are some of the tools that we're going to be exploring today. We'll use pnpm, which is, in my opinion, the package manager that you wanna use for TypeScript monorepos. Today we'll be using the latest version of Lerna, which, behind the scenes it is leaning on NX for a lot of things.

[00:03:02]
So we'll start with lerna and then we'll eject out to nx when we have I need to do so, we'll get through the package managers and the build tools. We'll use API extractor and documenter to create a very deliberately controlled API surface for each package in the monorepo.

[00:03:23]
It'll only matter for libraries in this case, but we'll get auto generated docs and we'll get what's called a declaration file rollup, which is the a single DTS file that represents the whole library and you'll be able to tag individual methods and fields, anything that's exported as internal or alpha or beta maturity and you'll get the right roll up generated depending on whether you're using alpha or beta features in this library or you're using the stable version.

[00:03:56]
We'll talk a little bit about GitHub code owners if you've ever used this before at your root repo level you can have a code owners file that governs who is automatic to review a pr and we'll talk about how to use that in a monorepo context. How can you store this same information in individual packages and have that sort of synchronized and pulled up to a root level code owners file that is purely kind of a build artifact.

[00:04:26]
Like you don't have to touch it because the source of truth lies within each package. And this gives you a lot of control over like maybe you have an infrastructure team that's responsible for some small set of packages and then you have other people that should be reviewing code in other places.

[00:04:42]
Then finally, even if you're well experienced with monorepos, I'm going to walk through a couple standalone tools that help detect and address common monorepo pitfalls, like the quality of each package's package JSON. Are you missing things in there? Does each have a homepage? Are you pointing to the correct place in a repository on GitHub where you could see the readme for that package, not for the whole monorepo.

[00:05:17]
De duping versions of packages across your Monorepo Syncpack is a great tool for that. If you have 16 versions of TypeScript across 20 packages in your monorepo, this is what will help alert you to that potentially in a quite automated way where you can just use fix. It'll consolidate you onto a version that you can use across the entire workspace.

[00:05:44]
We'll also work with a library called knip knip, which is great for identifying like needless exports from libraries that at least within the monorepo, nobody seems to be consuming, and it helps to identify unneeded packages in your package JSON, like unneeded dependencies in your package JSON. And like, why this is important for monorepos, well, we're going to end up with a bunch of package JSONs, so that work like curating your list of dev dependencies and dependencies.

[00:06:19]
It's multiplicative now, and these tools help make sure that you're not having to go into each package in your project and personally pare it down where you can see that there are things that nobody seems to be importing within the package.