Check out a free preview of the full JavaScript and TypeScript Monorepos course

The "Introduction" Lesson is part of the full, JavaScript and TypeScript Monorepos course featured in this preview video. Here's what you'd learn in this lesson:

Mike North defines monorepos as many related packages that are all located within the same git repository, explains that the main project of the course will be to build a Slack application, and gives an overview of the different topics covered in this course.


Transcript from the "Introduction" Lesson

>> Welcome to JavaScript and TypeScript repos. My name is Mike North. I'm a senior staff engineer at LinkedIn, where I lead the infrastructure as a product team. So I'm kind of a product designer for for software infrastructure. And one of the things I'm focused on is helping teams lots of engineers, Find a great developer experience.

mono repos are a big part of that. So the idea behind a mono repo is I mean, if we break it down, it's literally one repo. This word can be used to describe many things. And in fact it is. So if you talk to People who are, you know, not primarily focused in the JavaScript ecosystem, they may think it describes the way Google manages their source code.

For example, the whole company commits everything to one repository. We mean something specific today. And that is many related packages. Usually packages that have interdependencies between them, right, they're deeply entangled, they're all located in a single git repository. We're gonna learn about this today in the context of a Slack app.

So, if you look at this app, many things going on. Right, you can have all of these different concerns. You have some UI components, you have a data layer things that are fetching, JSON, you have some utilities like for date formatting. And then we have some types because this project is going to be written in TypeScript although you don't need to know TypeScript At all today in order to take this course.

What we'll get by structuring this as a mono repo, we can break it apart, and we can treat it as independent layers, each of which has a great encapsulation boundary around it. So it's almost like within the same Git repo, we have three small libraries Then I'll come together to become an app.

And you can imagine how we could use the same three libraries to create a COI or an API. Or maybe we have a desktop and a mobile web experience that are a little bit different. We have lots of options here because we, we have these composable building blocks, instead of just one big pool of code.

So why should you care about monorepos? Well I mentioned that they are a great encapsulation tool that otherwise would not be able to get in the job ecosystem. You have low overhead of making changes. So if you make a change that affects types And a web component and the data layer, you can just have a single commit and a single pull request that will do everything that's needed to be done.

And, and that's it. The alternative would be, you know, treating these as fully independent libraries, and you'd need to Make a small change, cut a release and thread all of that through many releases. It's a lot more work. You also get the ability to test everything together before you cut a release.

The other approach I just mentioned, where you have individual libraries each in their own repo. There's a possibility that you only find out at the end. When you're bringing things through propagating things through your dependency tree. You only find out problems as you reach those last steps. Today I hope to show you how you get a lot of the benefits of using many libraries.

With the overhead of one Git repository, right, a lot lower than maintaining a bunch of independent libraries. So like anything, I want to make sure we don't treat this as a cure all. There are a few new tools that we're going to have to learn. And there are some new risks, duplicate dependencies is one of the things we're goa e talking about.

So, it's important to understand that this is not a pattern it's just better than a typical monolith project structure. There are cases where it provides lots of benefits and today we're gonna learn how to identify those cases. And those those will be the good candidates, you know, to, to use a mono repo project structure for.

So not only are we gonna get a slack app out of this, we're gonna have some great API documentation and you can see here at the bottom of the screen We have all these different packages, data layer types, our UI, which is our components, and then utilities, each of which is going to have a nice little like homepage for this little package within our app.

And then you can see that we're able to have great documentation for functions and for types. And so I will show you how to use a tool that sort of brings all of this together into one documentation site, not one site per package. In order to learn about mono repos.

Today we're going to address a series of topics and the the point of ordering things the way I've chosen to order them today is I want us to start with a very basic, mostly empty project. And I want us to layer up piece by piece, all of this tooling that you typically would end up using when working with a mono repo.

By the end of this course you're going to understand exactly what each thing does and you'll be able to feel, How it is to work with the project before you add it and after. And this was a big pain point for me when I was learning this kind of tooling.

I you know, you're just given like six or seven new CL eyes and you're not necessarily it's not clear who does what thing right So we'll start with yarn workspaces. We will use the composite project feature of the TypeScript compiler that can work with JavaScript or TypeScript. So don't worry if you're not used to TypeScript, this would still be a very useful thing for you to Incorporate into your app.

We're going to work a little bit with some build scripts. We're gonna then deal with the learner which makes it easy to almost have like a four loop where you'd say for each package I want to run this command. Well, we will experiment with API extractor which is a documentation tool from Microsoft.

That helps us understand what our public API surface looks like. And we will even set up our own private NPM registry using a project called verragio. And that will let us experiment with publishing packages. right you are going to be publishing some packages today, although not to the real NPM You'll just publish them to your own own machine.

And that will let us play with some versioning strategies. So, with that, it's time for us to jump into the workshop project and get our hands on some code. So this bitly link is where you can find the GitHub repository. There is a folder called notes. Make sure you look at that because those are all the markdown notes for each of the steps we're gonna be taking today.

Be sure you look at the readme carefully. There are a few tools that you may not have used before. And I wanna make sure that you have everything set up so that you will have a good time going through this course.

Learn Straight from the Experts Who Shape the Modern Web

  • In-depth Courses
  • Industry Leading Experts
  • Learning Paths
  • Live Interactive Workshops
Get Unlimited Access Now