Monorepos sind 2026 der Standard für skalierbare TypeScript-Projekte. Turborepo von Vercel ist das schnellste Build-System für JavaScript-Monorepos — mit intelligentem Caching, paralleler Task-Ausführung und nahtloser CI-Integration. Kombiniert mit Claude Code als AI-Pair-Programmer entstehen produktive Setups in Minuten statt Stunden.

⚡

Parallele Builds

Tasks laufen gleichzeitig — Turborepo erkennt Abhängigkeiten automatisch.

🗄️

Remote Cache

Build-Artefakte werden teamweit geteilt — CI-Zeiten reduzieren sich drastisch.

📦

Shared Packages

UI-Komponenten, Config und TypeScript-Definitionen einmal — überall genutzt.

🔍

Affected-only

Nur geänderte Pakete werden getestet und deployed — kein unnötiger Overhead.

1. Turborepo Setup

Der schnellste Einstieg in Turborepo ist via create-turbo. Claude Code generiert das komplette Scaffold inklusive pnpm-Workspaces, turbo.json und einer sinnvollen Paketstruktur — in einem einzigen Prompt.

Turborepo initialisieren Setup
Terminal
# Neues Turborepo-Projekt erstellen npx create-turbo@latest my-monorepo cd my-monorepo # Package Manager: pnpm (empfohlen) pnpm install # Struktur ansehen tree -L 3 --dirsfirst

Nach dem Scaffold entsteht folgende Workspace-Struktur — Claude Code versteht diese Konvention und kann Pakete direkt in die richtige Ebene einordnen:

Projektstruktur
my-monorepo/ ├── apps/ │ ├── web/ # Next.js Frontend │ │ ├── package.json │ │ └── src/ │ └── docs/ # Docusaurus / weitere App │ └── package.json ├── packages/ │ ├── ui/ # Shared UI-Komponenten │ ├── config/ # ESLint, Prettier, etc. │ └── tsconfig/ # TypeScript-Konfigurationen ├── turbo.json # Pipeline-Konfiguration ├── package.json # Root Workspace └── pnpm-workspace.yaml

Die Root-package.json definiert die Workspaces und enthält keine eigene Applikationslogik:

package.json (Root)
{ "name": "my-monorepo", "private": true, "scripts": { "build": "turbo run build", "dev": "turbo run dev", "lint": "turbo run lint", "test": "turbo run test", "format": "prettier --write \"**/*.{ts,tsx,md}\"" }, "devDependencies": { "turbo": "^2.0.0", "typescript": "^5.4.0", "prettier": "^3.2.0" }, "engines": { "node": ">=20.0.0", "pnpm": ">=9.0.0" } }
pnpm-workspace.yaml
packages: - "apps/*" - "packages/*"
Claude Code Prompt: "Erstelle ein Turborepo-Monorepo mit pnpm-Workspaces. Apps: web (Next.js 15), api (Hono). Packages: ui, config, tsconfig. Generiere alle package.json-Dateien und die turbo.json-Pipeline."

2. Pipeline-Konfiguration

Die turbo.json ist das Herzstück jedes Turborepo-Projekts. Sie definiert, welche Tasks existieren, wie sie voneinander abhängen, was gecacht wird und welche Eingaben das Cache-Verhalten steuern.

Vollständige Pipeline-Konfiguration Pipeline
turbo.json
{ "$schema": "https://turbo.build/schema.json", "globalDependencies": ["**/.env.*local", ".env"], "globalEnv": ["NODE_ENV", "VERCEL_ENV"], "tasks": { "build": { "dependsOn": ["^build"], "inputs": ["src/**", "!src/**/*.test.ts"], "outputs": [".next/**", "!.next/cache/**", "dist/**"], "env": ["NEXT_PUBLIC_API_URL"] }, "test": { "dependsOn": ["build"], "inputs": ["src/**", "tests/**"], "outputs": ["coverage/**"], "cache": true }, "lint": { "dependsOn": [], "inputs": ["src/**", "*.{js,ts,json}"], "outputs": [] }, "dev": { "cache": false, "persistent": true }, "clean": { "cache": false }, "typecheck": { "dependsOn": ["^build"], "inputs": ["src/**/*.ts", "src/**/*.tsx", "tsconfig.json"], "outputs": [] } } }

Pipeline-Konzepte verstehen

Die Schlüsselkonzepte der turbo.json-Pipeline:

Performance-Tipp: Die inputs-Konfiguration ist entscheidend für Cache-Effizienz. Je präziser die Inputs, desto seltener Cache-Misses. Claude Code kann die optimalen Input-Patterns für jedes Paket vorschlagen.

3. Shared Packages

Shared Packages sind der größte Effizienz-Gewinn in einem Monorepo. UI-Komponenten, TypeScript-Konfigurationen und ESLint-Regeln werden einmal definiert und in allen Apps genutzt — ohne Duplikation.

@repo/ui — Shared UI Package Shared
packages/ui/package.json
{ "name": "@repo/ui", "version": "0.0.0", "private": true, "exports": { ".": { "types": "./src/index.ts", "default": "./src/index.ts" }, "./button": { "types": "./src/components/Button.tsx", "default": "./src/components/Button.tsx" }, "./card": { "types": "./src/components/Card.tsx", "default": "./src/components/Card.tsx" } }, "scripts": { "lint": "eslint . --max-warnings 0", "typecheck": "tsc --noEmit" }, "devDependencies": { "@repo/tsconfig": "*", "@types/react": "^18.3.0", "typescript": "^5.4.0" }, "peerDependencies": { "react": "^18.0.0 || ^19.0.0", "react-dom": "^18.0.0 || ^19.0.0" } }
packages/tsconfig/package.json
{ "name": "@repo/tsconfig", "version": "0.0.0", "private": true, "exports": { "./base.json": "./base.json", "./nextjs.json": "./nextjs.json", "./react-library.json": "./react-library.json", "./node.json": "./node.json" } }
packages/tsconfig/base.json
{ "compilerOptions": { "target": "ES2022", "lib": ["ES2022"], "module": "ESNext", "moduleResolution": "bundler", "strict": true, "skipLibCheck": true, "declaration": true, "declarationMap": true, "sourceMap": true, "esModuleInterop": true, "resolveJsonModule": true, "isolatedModules": true } }

Package in Apps verwenden

apps/web/package.json (Auszug)
{ "name": "web", "dependencies": { "@repo/ui": "*", "next": "^15.0.0", "react": "^19.0.0" }, "devDependencies": { "@repo/tsconfig": "*", "@repo/config": "*" } }
apps/web/tsconfig.json
{ "extends": "@repo/tsconfig/nextjs.json", "compilerOptions": { "paths": { "@/*": ["./src/*"] } }, "include": ["src"], "exclude": ["node_modules"] }
Best Practice: Verwende "*" als Version für interne Pakete in pnpm-Workspaces. pnpm resolved das automatisch auf den lokalen Workspace — kein npm-Publishing nötig.

4. Remote Caching

Remote Caching ist Turborepos Killer-Feature für Teams. Build-Artefakte werden in einem gemeinsamen Cache gespeichert — ein Entwickler baut, alle anderen überspringen identische Tasks. CI-Pipelines profitieren am stärksten.

Vercel Remote Cache einrichten Remote Cache
Terminal
# 1. Bei Vercel anmelden (einmalig) npx turbo login # 2. Repo mit Vercel Remote Cache verknüpfen npx turbo link # 3. Erster Build — Artefakte werden hochgeladen pnpm build # 4. Zweiter Build — alles aus Cache (FULL TURBO) pnpm build # >>> FULL TURBO (0 Tasks ausgeführt)

Eigener Cache-Server (Self-hosted)

Für Projekte ohne Vercel-Anbindung gibt es den offiziellen @turborepo/remote-cache Server oder kompatible Alternativen wie ducktape und turborepo-remote-cache (open source).

turbo.json — Custom Cache-Server
{ "$schema": "https://turbo.build/schema.json", "remoteCache": { "enabled": true, "apiUrl": "https://cache.my-company.com", "signature": true }, "tasks": { // ... deine Pipeline } }
.env (für lokale Entwicklung)
TURBO_TOKEN=your-cache-token TURBO_TEAM=your-team-slug TURBO_API=https://cache.my-company.com
Self-hosted Cache mit Docker
# docker-compose.yml für turborepo-remote-cache services: turbo-cache: image: fox1t/turborepo-remote-cache:latest ports: - "3000:3000" environment: NODE_ENV: production TURBO_TOKEN: your-secret-token STORAGE_PROVIDER: s3 S3_BUCKET: turbo-cache volumes: - turbo-cache-data:/app/cache
Cache-Analytics: turbo run build --summarize generiert einen detaillierten JSON-Report über Cache-Hits, Task-Dauer und Task-Graph. Ideal um Bottlenecks zu finden.

5. Filtering und Task-Running

Turborepos --filter-Flag ist eines der mächtigsten Features im täglichen Workflow. Es ermöglicht gezieltes Ausführen von Tasks nur für bestimmte Pakete oder solche, die sich seit einem bestimmten Git-Commit geändert haben.

Filter-Patterns Filtering
Terminal — Filter-Beispiele
# Nur eine spezifische App bauen turbo run build --filter=web # App inklusive aller Abhängigkeiten bauen turbo run build --filter=web... # Alle Apps die von @repo/ui abhängen turbo run build --filter=...@repo/ui # Nur Pakete die sich seit main geändert haben turbo run build --filter=[origin/main] # Alle Pakete seit letztem Git-Tag turbo run test --filter=[HEAD^1] # Kombiniert: web + geänderte Pakete turbo run build --filter=web --filter=[origin/main] # Dev-Server für alle Apps parallel turbo run dev --parallel # Nur apps/ (nicht packages/) turbo run dev --filter="./apps/*"

Nützliche Task-Kombinationen

package.json Scripts (optimiert)
{ "scripts": { // Alle Apps bauen (inkl. package-Abhängigkeiten) "build": "turbo run build", // Nur veränderte Pakete testen (CI-Optimierung) "test:affected": "turbo run test --filter=[origin/main]", // Vollständiger CI-Check "ci": "turbo run build lint typecheck test", // Dev mit Concurrency-Limit "dev": "turbo run dev --concurrency=10", // Workspace-übergreifendes Typecheck "typecheck": "turbo run typecheck", // Cache analysieren "analyze": "turbo run build --summarize --dry=json" } }

Dry-Run und Graph-Visualisierung

Terminal
# Zeigt welche Tasks ausgeführt würden (ohne Ausführung) turbo run build --dry # Task-Graph als DOT-Format exportieren turbo run build --graph=graph.dot # Als SVG rendern (graphviz erforderlich) dot -Tsvg graph.dot -o graph.svg # Turbo-Daemon-Status prüfen turbo daemon status
Achtung bei --parallel: Das Flag deaktiviert Turborepo-Abhängigkeitserkennung und führt alle Tasks gleichzeitig aus — nur für unabhängige Tasks wie dev verwenden. Für build den normalen Task-Graph nutzen.

6. CI/CD Integration

Turborepo entfaltet seinen vollen Nutzen in CI/CD-Pipelines. Mit Remote Cache und Affected-only-Builds reduzieren sich CI-Zeiten um 60–90%. Claude Code generiert GitHub Actions Workflows, die beide Features optimal nutzen.

GitHub Actions mit Turborepo CI/CD
.github/workflows/ci.yml
name: CI on: push: branches: [main, develop] pull_request: branches: [main] env: TURBO_TOKEN: ${{ secrets.TURBO_TOKEN }} TURBO_TEAM: ${{ vars.TURBO_TEAM }} jobs: build-and-test: runs-on: ubuntu-latest strategy: matrix: node-version: ['20', '22'] steps: - uses: actions/checkout@v4 with: fetch-depth: 0 # Für --since/--filter=[origin/main] - name: Setup pnpm uses: pnpm/action-setup@v4 with: version: 9 - name: Setup Node.js ${{ matrix.node-version }} uses: actions/setup-node@v4 with: node-version: ${{ matrix.node-version }} cache: pnpm - name: Install dependencies run: pnpm install --frozen-lockfile - name: Build run: pnpm turbo run build --filter=[origin/main] - name: Lint run: pnpm turbo run lint - name: Typecheck run: pnpm turbo run typecheck - name: Test (affected only) run: pnpm turbo run test --filter=[origin/main] - name: Upload Turbo summary if: always() uses: actions/upload-artifact@v4 with: name: turbo-summary path: .turbo/runs

Affected-only Deployments

.github/workflows/deploy.yml (Auszug)
jobs: detect-changes: runs-on: ubuntu-latest outputs: web-changed: ${{ steps.turbo.outputs.web }} api-changed: ${{ steps.turbo.outputs.api }} steps: - uses: actions/checkout@v4 with: { fetch-depth: 0 } - name: Detect affected packages id: turbo run: | WEB=$(turbo run build --filter=web --dry=json | jq '.tasks | length') echo "web=$([[ $WEB -gt 0 ]] && echo true || echo false)" >> $GITHUB_OUTPUT deploy-web: needs: detect-changes if: needs.detect-changes.outputs.web-changed == 'true' runs-on: ubuntu-latest steps: - name: Deploy web to Vercel run: vercel --prod --token=${{ secrets.VERCEL_TOKEN }}

Turbo für GitHub Actions optimieren

turbo.json — CI-spezifische Konfiguration
{ "$schema": "https://turbo.build/schema.json", "remoteCache": { "enabled": true, "signature": true }, "tasks": { "build": { "dependsOn": ["^build"], "outputs": ["dist/**", ".next/**", "!.next/cache/**"], "env": [ "NODE_ENV", "NEXT_PUBLIC_*" ] } } }
CI Cache-Tipp: Setze fetch-depth: 0 in actions/checkout — ohne vollständige Git-History kann Turborepo --filter=[origin/main] nicht korrekt auflösen und fällt auf einen Full-Build zurück.

Fazit: Turborepo + Claude Code = produktives Monorepo

Turborepo ist 2026 die erste Wahl für TypeScript-Monorepos — mit intelligentem Caching, klaren Pipeline-Definitionen und nahtloser CI-Integration. Claude Code beschleunigt das Setup erheblich: turbo.json-Pipelines, package.json-Exports und GitHub Actions Workflows entstehen durch präzise Prompts in Minuten.

Die Kombination aus Remote Cache, Affected-only-Builds und Shared Packages macht Turborepo besonders wertvoll für wachsende Teams. Wer einmal die Produktivitätsgewinne erlebt hat — Build-Zeiten von Minuten auf Sekunden, geteilte Komponenten ohne Duplikation, CI-Läufe die nur das Nötige testen — kehrt nicht mehr zu traditionellen Multi-Repo-Setups zurück.