Monorepo and Workspaces
Learn how to structure a monorepo using pnpm workspaces and Turborepo, share code across apps, version packages, and run fast CI pipelines that only build what changed.
What you'll learn
Course outline
Free — no account needed
What Is a Monorepo and When Does It Make Sense
Monorepo vs polyrepo tradeoffs, who uses them, and the tooling landscape
pnpm Workspaces — Setting Up Your First Monorepo
Install pnpm, configure workspaces, and link your first shared package
Turborepo — Caching and Parallelising Builds
Configure turbo.json, enable caching, and cut your build times dramatically
Full course — $39 one-time
Shared Packages — UI Library, Config, and Types
Create packages/ui, packages/config, and packages/types and consume them across apps
Versioning and Publishing from a Monorepo
Use changesets to version and publish packages to npm from a monorepo
CI/CD for Monorepos
GitHub Actions with affected detection, caching in CI, and Turborepo remote cache
Real-World Monorepo Patterns
Next.js + Expo in one repo, env strategy, secrets management, and anti-patterns to avoid
Get the full course
7 lessons — practical, project-based, no fluff.
About this course
Monorepos let multiple applications and packages share code, a single CI pipeline, and coordinated versioning — all from one Git repository. They are used by Google, Facebook, Airbnb, and increasingly by independent developer teams who manage more than one related application. The pattern makes sense when you have: a web app and a mobile app sharing business logic, multiple microservices sharing types and utilities, or a component library used across several projects. This course covers the full monorepo setup — workspace configuration, Turborepo for build orchestration, shared packages, and CI/CD.
Monorepos are not for every team or every project. But when the fit is right, they eliminate a whole category of "dependency drift" problems — where the same utility function has subtly different implementations in different repos, where a breaking change in a shared type is not caught until runtime. This course covers both the setup and the judgment calls around when monorepos help and when they add complexity without benefit.
Frequently asked questions
What is the difference between a monorepo and a monolith?
A monolith is a single deployable application where all functionality is bundled together. A monorepo is a repository structure — multiple distinct applications and packages in one Git repo, each potentially deployed independently. You can have a monorepo with microservices, or a monolith in a single repo. The terms are orthogonal. Monorepos are about code organisation and sharing; monoliths are about deployment architecture.
Should I use npm, yarn, or pnpm workspaces?
pnpm workspaces are the current recommended choice for new monorepos — they are significantly faster than npm, use less disk space via content-addressable storage, and have strict dependency isolation that catches errors npm misses. Yarn workspaces are widely used in existing codebases and work well. npm workspaces are simpler but slower and have weaker isolation. If starting fresh, use pnpm. If your team already uses yarn, stick with it.
What does Turborepo add to a workspace setup?
npm/yarn/pnpm workspaces handle package installation and cross-package dependencies. Turborepo adds: intelligent task scheduling (run build only in packages that have changed), local and remote caching (skip builds whose output is already cached), and parallel task execution. Without Turborepo, running "build" in a 10-package monorepo rebuilds all 10 packages every time. With Turborepo, unchanged packages restore from cache in milliseconds. Remote caching shares the cache across CI runs and team members.
How do I share a TypeScript config across packages?
Create a packages/tsconfig package (or any name) that exports base tsconfig.json files. Each package extends it: `"extends": "@myrepo/tsconfig/base"`. Use TypeScript project references for type-checked cross-package imports. The TypeScript compiler then understands the dependency graph and only recompiles packages that have changed. This is significantly faster than running tsc in every package independently.
How does Changesets handle versioning in a monorepo?
Changesets is a tool for versioning and publishing packages from a monorepo. When you make a change, you run `pnpm changeset` and describe the change and its severity (major/minor/patch) for each affected package. Before release, you run `pnpm changeset version` which bumps package.json versions and updates CHANGELOGs, then `pnpm changeset publish` to publish to npm. It handles the dependency update cascade — if package A depends on package B and B has a change, A is also bumped.