What is a Monorepo?

Real-world analogy

What is it?

A monorepo is a single Git repository that contains multiple projects (frontend, backend, shared libraries). Tools like Turborepo and pnpm workspaces make it efficient by sharing dependencies and running tasks in parallel.

Real-world relevance

Companies like Google, Meta, and Microsoft use monorepos. Your NestJS backend and React frontend can share TypeScript types — change a type once, both sides update instantly!

Key points

• One Repository — A monorepo keeps your frontend app, backend API, shared libraries, and configuration all in a single Git repository. This means one place to clone, one set of pull requests, and one CI/CD pipeline. Changes that span multiple packages (like updating a shared API type) become a single atomic commit.
• Shared Code — Create a shared packages directory with common TypeScript types, utility functions, validation schemas, and configuration files. Both your React frontend and NestJS backend import from the same shared package. Change a type definition once and both sides update immediately — no copy-pasting or version drift between projects.
• Turborepo / Nx — Monorepo build tools like Turborepo and Nx understand your project dependency graph and only rebuild what actually changed. They cache build outputs, run independent tasks in parallel, and skip already-completed work. A change to only the frontend skips rebuilding the backend entirely, saving significant CI time.
• pnpm Workspaces — pnpm workspaces connect your project folders (apps/frontend, apps/backend, packages/shared) so they can import code from each other directly using the package name. No need to publish packages to npm — pnpm symlinks them locally. It also deduplicates shared dependencies to save disk space.
• Smart Builds — Instead of rebuilding everything from scratch, monorepo tools use content hashing to detect exactly what changed. If you only modified a CSS file in the frontend, the backend build is skipped entirely. For a monorepo with 50 packages, smart caching can reduce CI build times from 30 minutes to under 2 minutes.
• Shared Dependencies — In a monorepo, npm packages are installed once at the root level and shared by all projects. This means every package uses the exact same version of React, TypeScript, or any other dependency — eliminating version conflicts. Updating a dependency is a single change instead of updating it separately across multiple repositories.
• Easy Refactoring — Need to rename a shared interface or restructure a utility module? In a monorepo, your IDE can refactor across all packages at once and you immediately see any code that breaks. In separate repos, you would need to update and publish the shared package, then update each consumer individually — much slower and error-prone.
• Consistent Tooling & Standards — A monorepo lets you share ESLint configs, Prettier settings, TypeScript configs, and CI/CD workflows across all packages from a single root. Every project follows the same coding standards automatically. New packages inherit the team's quality standards by default instead of requiring manual setup each time.

Code example

// Typical monorepo structure:
my-project/
├── apps/
│   ├── frontend/     ← React app (Vite + TypeScript)
│   └── backend/      ← NestJS app
├── packages/
│   └── shared/       ← Shared types, utils
├── package.json      ← Root config
├── pnpm-workspace.yaml
└── turbo.json        ← Turborepo config

// pnpm-workspace.yaml
packages:
  - "apps/*"
  - "packages/*"

// In frontend, you can import shared types:
import { UserDTO } from '@myproject/shared';

// turbo.json — configure what to cache
{
  "tasks": {
    "build": {
      "dependsOn": ["^build"],
      "outputs": ["dist/**"]
    },
    "test": {
      "dependsOn": ["build"]
    }
  }
}

Line-by-line walkthrough

1. 1. Typical monorepo structure:
2. 2.
3. 3.
4. 4.
5. 5.
6. 6.
7. 7.
8. 8.
9. 9.
10. 10.
11. 11.
12. 12. pnpm-workspace.yaml
13. 13.
14. 14.
15. 15.
16. 16.
17. 17. In frontend, you can import shared types:
18. 18. Importing required dependencies
19. 19.
20. 20. turbo.json — configure what to cache
21. 21. Opening block
22. 22.
23. 23.
24. 24.
25. 25.
26. 26. Closing block
27. 27.
28. 28.
29. 29. Closing block
30. 30. Closing block
31. 31. Closing block

Spot the bug

// packages/shared/types.ts
export interface User { name: string; }

// apps/frontend/app.tsx
import { User } from '../../packages/shared/types';

Explain like I'm 5

Fun fact

Hands-on challenge

More resources

• Nx Documentation (Nx Official)
• Turborepo Documentation (Turborepo Official)
• Monorepos Explained (Fireship)