Transcript

One of the questions I get asked most often when it comes to project structure is, should I use a monorepo? Now let's start off with what a monorepo is. A monorepo is a single repository, in this case a git repository or any kind of source code control repository that contains multiple packages in it. So those would be multiple libraries or applications. Now by default, the Turbo Repo, Mono Repos that we're going to use in this course have two applications and three packages.

And the idea is pretty simple. You're just co-locating all of the code that you need together, including your application, your packages that you're going to rely on that may be custom, for example, a design system that you have in there, that's all going to be in that single repo. That makes it really easy to version and maintain, but it also means that that repo is going to get fairly large. So let's talk about some example scenarios where I think a monorepo is a good idea. First off, when you have multiple applications and there's a potential to share code or standards files and that's basically the setup of the TurboRepo off-the-shelf starter.

Another one is if you have a single application that has multiple deployment options. Say you've got a web version, a mobile version, and then a desktop version, maybe with Electron, and you're going to share a common core application and then some components. That's a fantastic way to use a monorepo. One more common case is when you have design system components and you want to be able to deploy those separately from the applications. You can certainly do that in a monorepo.

You can always deploy each package or application individually. That's not a problem. Another time when I use it is when I have packages that have self-contained business logic, like you've got a package full of API wrappers, or you've got a package full of business logic that you want to keep separate from the UI. So you're going to have your app that basically uses those packages to call out and you're going to be able to publish then those API wrappers or that logic as separate packages. Now there are some options when it comes to what monorepo you might want to use, PMPM, Yarn, and NPM all have workspace functionality built right into them.

And that workspace functionality is actually the core of monorepo. So it's actually at your fingertips without installing anything new. The monorepo packages like TurboRepo or NX or MoonRepo build tooling on top of that to make that just a whole lot easier to use. And they also include some performance upgrades and caching that make it really good when it comes to CI-CD. Now let's talk about the alternative to using monorepos in general.

If you've got an app that just is the app, then you might not use a monorepo or any kind of npm linking. An npm linking is the alternative to a monorepo. You're gonna have multiple repos, each has its own npm package. And then if you want to develop on an application and a particular package, you'd use npm or pnpm or yarn linking to create a live link as you're developing. And then when you finish your development you then push your changes both to the repo for the NPM module and also for the application module.

And that is actually one of the times when It is really not as great of a DX in comparison to a monorepo. This isn't something you necessarily need to decide right away when it comes to your application. You can actually migrate a single application or a single package into a monorepo pretty easily, but my recommendation would be to essentially start with a new Git repo, port that code into there, into that structure, and then continue development from that, and then just simply deactivate the older repo.

lesson

Should You Use a Monorepo?

Jack Herrington

One of the most frequently asked questions regarding project structure is whether to use a monorepo. Before jumping straight to the answer, let's start by defining what a monorepo is.

What is a Monorepo?

A monorepo is a single repository that contains multiple packages within it, with each package able to include multiple libraries or applications.

The idea behind a monorepo is simple: you co-locate all the necessary code together, including your application and any custom packages you rely on, such as a design system. This approach makes versioning and maintenance easier, but it also means that the repository can become fairly large.

By default, the TurboRepo monorepos used in this course contain two applications and three packages.

When to Use a Monorepo

Here are some scenarios where using a monorepo can be beneficial:

Multiple Applications with Shared Code: If you have multiple applications and there's potential to share code or standards files, a monorepo is a good choice. This is the default setup of the TurboRepo off-the-shelf starter.

Single Application with Multiple Deployment Options: When you have a single application with various deployment options, such as a web version, mobile version, and desktop version (e.g., using Electron), a monorepo allows you to share a common core application and components.

Separately Deployable Design System Components: If you have design system components that you want to deploy separately from the applications, a monorepo enables you to do so. You can deploy each package or application individually within a monorepo.

Packages with Self-Contained Business Logic: When you have packages containing self-contained business logic, such as API wrappers or business logic that you want to keep separate from the UI, a monorepo is useful. Your application can use these packages to make calls, and you can publish the API wrappers or logic as separate packages.

Monorepo Options

Several monorepo options are available. Package managers like PMPM, Yarn, and NPM have built-in workspace functionality, which forms the core of monorepos. This means you can leverage this functionality without installing anything new.

Monorepo packages like TurboRepo, NX, or MoonRepo provide additional tooling on top of the workspace functionality, making it easier to use. They also offer performance upgrades and caching, which are beneficial for CI/CD pipelines.

Alternatives to Monorepos

If you have an application that stands alone, you might not need a monorepo or any kind of NPM linking. NPM linking is an alternative approach to monorepos.

With NPM linking, you have multiple repositories, each with its own NPM package. When you want to develop on an application and a specific package simultaneously, you use NPM, PMPM, or Yarn linking to create a live link during development.

Once you finish development, you push your changes to both the NPM module repository and the application module repository. This approach can be less convenient compared to using a monorepo.

Migrating to a Monorepo

Migrating to a monorepo doesn't have to be a decision made immediately. You can easily migrate a single application or package into a monorepo structure.

To migrate, it's recommended to start with a new Git repository, port the existing code into the monorepo structure, and continue development from there. You can then deactivate the older repository.

By understanding the scenarios where monorepos shine and the options available, you can make an informed decision on whether to adopt a monorepo structure for your projects.

Code Quality From the Start

Project Structure

Storybook

Unit Testing

End-to-End Testing

Automated Quality Enforcement

Monorepos

Advanced Component Structure

Transcript

Should You Use a Monorepo?

What is a Monorepo?

When to Use a Monorepo

Monorepo Options

Alternatives to Monorepos

Migrating to a Monorepo

Transcript