Comparisons

Turborepo vs Nx vs Lerna: AI Rules for Each

The three major monorepo tools take different approaches to task orchestration, caching, and workspace management. Each needs specific AI rules for pipeline configuration, dependency management, and code generation.

8 min read·May 1, 2025

turbo build, nx build, lerna run — three tools, three configs, three ecosystems that must not mix

Task pipelines, project graph, versioning, code generators, remote caching, and when to use each

Three Tools, Different Strengths

Turborepo, Nx, and Lerna are all monorepo tools, but they solve different primary problems. Turborepo: task orchestration and caching. Define a pipeline (build depends on ^build), Turborepo runs tasks in the correct order with maximum parallelism, and caches results (local and remote). Turborepo is: fast, simple configuration, and focused on making existing package managers (pnpm, npm, yarn) work better in monorepos. It does not generate code or manage versioning.

Nx: a full monorepo platform. Project graph analysis (understands dependencies between projects), affected commands (only build/test what changed), code generators (scaffolding new packages, components, and modules), plugins (framework-specific optimizations for React, Angular, Node), and remote caching (Nx Cloud). Nx is: comprehensive, opinionated, and provides the most features — but with more configuration complexity.

Lerna: versioning and publishing for monorepo packages. Lerna's primary purpose: manage npm package versions across a monorepo and publish them together or independently. Lerna delegates task running to other tools (Nx integration since Lerna 6, or Turborepo). Lerna is: focused on the publish workflow, not on build orchestration. In 2026, Lerna is primarily used alongside Nx or Turborepo, not as a standalone task runner.

Turborepo: Task Pipeline Rules

Turborepo configuration: turbo.json at the monorepo root. Define task pipelines: { "tasks": { "build": { "dependsOn": ["^build"], "outputs": ["dist/**"] }, "test": { "dependsOn": ["build"] }, "lint": {} } }. ^build means: build dependencies first (topological order). outputs specifies cache artifacts. Turborepo runs tasks with maximum parallelism within dependency constraints. AI rule: 'Turborepo: configure pipelines in turbo.json. Use ^dependency for topological ordering. Define outputs for cache. Run: turbo build, turbo test, turbo lint.'

Remote caching: Turborepo can cache build artifacts remotely (Vercel Remote Cache or self-hosted). If a package has not changed since the last build: Turborepo downloads the cached output instead of rebuilding. For CI: dramatically reduces build time (only changed packages rebuild, everything else is cached). AI rule: 'Enable remote caching for CI. Set TURBO_TOKEN and TURBO_TEAM environment variables. turbo build uses remote cache automatically. Cache artifacts: dist/, .next/, coverage/.'

Turborepo limitations to rule: Turborepo does not generate code (no scaffold commands), does not manage versions (no version bumping or changelogs), and does not analyze the project graph for affected detection (it runs all matching tasks unless filtered with --filter). AI rule: 'Turborepo: task orchestration and caching only. For code generation: use pnpm create or custom scripts. For versioning: use changesets or Lerna. For affected detection: use --filter with git diff.'

  • turbo.json: task pipelines with ^dependency ordering and output caching
  • Remote cache: Vercel or self-hosted, dramatic CI speedup for unchanged packages
  • Run: turbo build (all packages), turbo build --filter=web (specific package)
  • No code generation, no versioning, no affected detection — focused on task orchestration
  • Pairs with: pnpm workspaces (package management) + changesets (versioning)
ℹ️ Remote Cache = CI Speedup from Minutes to Seconds

Unchanged package since last build: Turborepo downloads the cached output from Vercel Remote Cache in 2 seconds instead of rebuilding in 2 minutes. For a 10-package monorepo: 8 cached + 2 rebuilt = 4 minutes CI instead of 20 minutes. Same code, same results, 5x faster.

Nx: Project Graph and Generator Rules

Nx configuration: nx.json at the monorepo root + project.json per project (or inferred from package.json). Nx builds a project graph by analyzing imports and dependencies. nx affected --target=test runs tests only for projects affected by the current changes. Generators: nx generate @nx/react:component Button --project=ui creates a new component with tests and exports. AI rule: 'Nx: use nx affected for changed-only builds/tests. Use generators for scaffolding. project.json for per-project configuration.'

Nx plugins: framework-specific optimizations. @nx/next (Next.js build optimization), @nx/react (component generators, test setup), @nx/node (Node.js app and library generators), @nx/jest (test configuration), @nx/eslint (lint configuration). Plugins provide: generators (scaffold new projects and components), executors (optimized build/test/serve commands), and migrations (automatic updates when the plugin version changes). AI rule: 'Use Nx plugins for framework integration. nx generate for scaffolding. Plugin executors for build/test/serve.'

Nx Cloud: remote caching and distributed task execution. Similar to Turborepo remote cache but with additional features: distributed task execution (spread CI tasks across multiple machines), task replay (view cached build logs), and project graph visualization. AI rule: 'Nx Cloud for remote caching in CI. Set NX_CLOUD_ACCESS_TOKEN. nx affected runs only changed projects. Distributed execution for large monorepos.'

  • Project graph: Nx analyzes imports to understand project dependencies
  • nx affected: only build/test projects impacted by the current changes
  • Generators: nx generate scaffolds new projects, components, and modules
  • Plugins: framework-specific (@nx/next, @nx/react, @nx/node) with executors and migrations
  • Nx Cloud: remote cache + distributed execution + task replay
💡 Only Build What Changed

nx affected --target=test: Nx analyzes the project graph, finds which projects are impacted by the current git changes, and runs tests only for those projects. 50-project monorepo, 3 projects changed: 3 test runs instead of 50. Turborepo: use --filter with git diff for similar (manual) affected detection.

Lerna: Versioning and Publishing Rules

Lerna configuration: lerna.json at the monorepo root. Primary commands: lerna version (bump package versions based on conventional commits or manual selection), lerna publish (publish packages to npm), and lerna run (delegate to Nx or Turborepo for task execution). Since Lerna 6: Nx is integrated for task orchestration. Lerna's unique value: the version and publish workflow for npm packages. AI rule: 'Lerna: use for versioning (lerna version) and publishing (lerna publish). Task running: delegate to Nx (useNx: true in lerna.json).'

Versioning modes: fixed mode (all packages share one version number — like Angular) and independent mode (each package has its own version — like Babel). Fixed: lerna version patch bumps all packages from 1.2.3 to 1.2.4. Independent: lerna version prompts for each changed package individually. Conventional commits: lerna version --conventional-commits reads commit messages to determine version bumps (feat: = minor, fix: = patch, BREAKING CHANGE: = major). AI rule: 'Version mode in lerna.json. Fixed for coordinated releases. Independent for library collections. Use conventional commits for automatic version determination.'

Lerna limitations: Lerna is not a build tool (it delegates to Nx or Turborepo), does not provide code generators (use Nx generators or manual creation), and does not provide remote caching (use Nx Cloud or Vercel Remote Cache). In 2026, Lerna is primarily the versioning layer in a Turborepo or Nx monorepo. AI rule: 'Lerna: versioning and publishing only. Build orchestration: Turborepo or Nx. Code generation: Nx generators or custom scripts. Caching: Turborepo or Nx Cloud.'

Choosing: When to Use Each

Use Turborepo when: you want the simplest monorepo setup (turbo.json + pnpm workspaces), you do not need code generators or affected detection, your monorepo has 5-20 packages, and you want fast setup with minimal configuration. Turborepo + pnpm workspaces + changesets is the lightweight stack. AI rule: 'Simple monorepo: Turborepo + pnpm workspaces. turbo.json for pipelines. changesets for versioning.'

Use Nx when: you want the most comprehensive tooling (affected detection, generators, plugins), your monorepo has 20+ projects, you need framework-specific optimizations (Angular, React, Next.js build plugins), or your team values scaffolding consistency (generators enforce structure). Nx is the enterprise stack. AI rule: 'Large monorepo: Nx with plugins. nx.json + project.json per project. Generators for consistency. Affected for CI efficiency.'

Use Lerna when: you publish npm packages from a monorepo and need coordinated versioning and publishing. Lerna is the publishing layer, not the build layer. Use Lerna + Nx (useNx: true) or Lerna + Turborepo for the full workflow: Turborepo/Nx for builds, Lerna for versioning and npm publish. AI rule: 'Publishing npm packages: add Lerna for versioning + publishing. Build orchestration: keep Turborepo or Nx. Lerna version + lerna publish for release workflow.'

  • Simple (5-20 packages): Turborepo + pnpm workspaces + changesets
  • Comprehensive (20+ projects): Nx + plugins + generators + Nx Cloud
  • Publishing npm packages: Lerna for version + publish, Turborepo/Nx for builds
  • Turborepo: simplest config, fast caching. Nx: most features, steeper learning curve
  • Lerna: no longer a standalone build tool — the versioning companion for Turborepo or Nx
⚠️ Lerna Is No Longer a Build Tool

Lerna in 2026: versioning and npm publishing only. Task orchestration: delegate to Turborepo (fast pipelines) or Nx (affected detection + generators). Using lerna run for builds: works but you miss caching and parallelism. Add Turborepo or Nx for the build layer, keep Lerna for the publish layer.

Ready-to-Use Rule Templates

Turborepo CLAUDE.md template: '# Monorepo (Turborepo + pnpm). Workspaces: pnpm-workspace.yaml. Task pipelines: turbo.json. Run: turbo build, turbo test, turbo lint. Filter: turbo build --filter=packages/web. Cache: outputs in turbo.json (dist/**, .next/**). Remote cache: Vercel. Versioning: changesets (pnpm changeset, pnpm changeset version). Package manager: pnpm (pnpm add, pnpm install). Never Nx commands (nx affected, nx generate).'

Nx CLAUDE.md template: '# Monorepo (Nx). Config: nx.json + project.json per project. Run: nx build web, nx test api, nx affected --target=test. Generate: nx generate @nx/react:component Button --project=ui. Plugins: @nx/next, @nx/react, @nx/node for framework integration. Cache: Nx Cloud (NX_CLOUD_ACCESS_TOKEN). Affected: nx affected only runs changed projects. Never Turborepo commands (turbo build, turbo.json pipelines).'

Lerna CLAUDE.md template: '# Versioning (Lerna + Turborepo). Lerna: versioning and publishing only. Config: lerna.json with useNx or pipeline delegation. Version: lerna version --conventional-commits. Publish: lerna publish from-package. Build: turbo build (Turborepo handles task orchestration). Mode: independent (each package versioned separately). Never use lerna run for builds — delegate to Turborepo or Nx.'

Comparison Summary

Summary of Turborepo vs Nx vs Lerna AI rules.

  • Turborepo: task orchestration + caching (turbo.json pipelines, Vercel remote cache)
  • Nx: full platform (project graph, affected, generators, plugins, Nx Cloud)
  • Lerna: versioning + publishing (lerna version, lerna publish, npm package releases)
  • Simple monorepo: Turborepo + pnpm + changesets. Complex: Nx + plugins. Publishing: add Lerna
  • Turborepo: no generators, no affected. Nx: both. Lerna: neither (delegates to Turborepo/Nx)
  • Remote cache: Turborepo (Vercel) vs Nx (Nx Cloud) — both dramatically reduce CI time
  • Config: turbo.json (Turborepo) vs nx.json + project.json (Nx) vs lerna.json (Lerna)
  • Templates: never mix tool commands — turbo build and nx build are different ecosystems