Turborepo + pnpm: The ‘Powerful’ Combo for Smoother Monorepo Management

Have you ever gone crazy managing dozens of disjointed repositories?

Imagine you are juggling three projects: a web app, an admin site, and an API system. Every time you modify a shared utility function (utils) or a UI component, you have to open three IDE windows, copy-paste code, and painstakingly update each one. It’s too time-consuming! Monorepos were born to end that pain.

Practically speaking, a Monorepo brings all projects and packages under one “roof”. However, simply putting them in the same folder without coordination tools will soon result in a mess. That’s why we need pnpm for library management and Turborepo to accelerate execution.

Deploy a Monorepo in 5 Minutes

Instead of just listening to theory, let’s build a sample project right away. Open your terminal and type:

npx create-turbo@latest

Now, choose pnpm when asked about the package manager. After installation, your project structure will look like this:

• apps/: Where main products like web, dashboard, or blog are stored.
• packages/: A repository for shared libraries like UI, Config, and Utils.
• turbo.json: The roadmap that tells Turborepo how to run the project.

Just run the command pnpm dev, and Turborepo will automatically activate development mode for all applications simultaneously. It feels extremely professional and organized.

Why are pnpm and Turborepo the “Perfect Match”?

pnpm – Save Dozens of Gigabytes of Disk Space

npm and yarn often create heavy node_modules folders. With pnpm, the “Content-addressable store” mechanism saves only one copy of each library on your hard drive. In reality, when I switched from npm to pnpm for a repo with five React projects, the storage usage dropped from 2GB to just over 400MB. In a Monorepo, pnpm’s Workspaces feature helps sub-projects connect with each other without needing to push code to an npm registry.

Turborepo – Never Do the Same Work Twice

If pnpm handles the “assets”, then Turborepo is the production manager. Its strongest weapon is Caching. If application A’s code hasn’t changed, Turborepo will retrieve the results from the previous build in just a few milliseconds.

In a real project with five developers, I integrated this workflow, and the results were surprising. CI/CD build times dropped from 10 minutes to less than 2 minutes thanks to the smart caching mechanism. You no longer have to wait pointlessly for code that hasn’t even changed.

Sharing Code: Update Once, Apply Everywhere

The best part is that you can create a shared UI package for both Web and Admin. Suppose you have packages/ui containing custom buttons. To use it in apps/web, simply declare it in the package.json file:

{
  "dependencies": {
    "@repo/ui": "workspace:*"
  }
}

The workspace:* symbol signals to pnpm: “Prioritize getting the latest version directly within this repo”.

Flexible Pipeline Configuration

You need to teach Turborepo the order of tasks via the turbo.json file:

{
  "pipeline": {
    "build": {
      "dependsOn": ["^build"],
      "outputs": [".next/**", "dist/**"]
    },
    "lint": {},
    "dev": {
      "cache": false,
      "persistent": true
    }
  }
}

The ^ character has a very logical meaning: all dependencies must finish building before the package itself can be built. The system will always run in the correct order without requiring manual intervention.

3 Tips for Smooth Monorepo Management

Here are the “hard-won” experiences I’ve gathered:

1. Use Filters: Never build the entire repo if you’ve only modified the Web app. Use the command: pnpm build --filter=web to save time.
2. Split Packages: Instead of creating one giant utils chunk, split it into utils-auth and utils-api. This helps caching work more accurately, preventing the system from rebuilding the API part when you only change auth code.
3. Enable Remote Caching: When working in a team, use Vercel Remote Cache. If a colleague has already finished a build on their machine, your machine will simply download that result. This is truly a revolution for team productivity.

Switching to a Monorepo might be a bit confusing for the first few days. However, once you get used to this speed and order, you will never want to go back to fragmented management. Good luck building optimized and sustainable systems!