Nx Monorepo mit Claude Code: Multi-App Workspaces 2026

Nx vs. Turborepo: Wann Nx wählen?

Beide Tools lösen das Monorepo-Problem — aber mit unterschiedlicher Tiefe. Turborepo ist schlanker und schneller eingerichtet; Nx bietet ein vollständiges Workspace-Ökosystem mit Generatoren, Plugins und einer eigenen IDE-Integration.

Kriterium	Nx	Turborepo
Affected-Analyse	✓ granular (Task-Graph)	△ Pipeline-basiert
Generatoren / Schematics	✓ umfangreich	✗ nicht vorhanden
Remote Caching	✓ Nx Cloud (gratis Tier)	✓ Vercel Remote Cache
Module Federation	✓ @nx/module-federation	✗ manuell
Plugin-Ökosystem	✓ React, Angular, Node, Rust…	△ begrenzt
Lernkurve	△ mittel	✓ flach
Claude Code Integration	✓ project.json → Task-Kontext	△ turbo.json

🎯 Wähle Nx wenn…

…du mehr als 3 Apps, gemeinsame Libraries und ein Team mit >2 Entwicklern hast. Nx skaliert besser und Claude Code versteht den strukturierten project.json-Ansatz besonders gut — es kann Affected-Targets eigenständig analysieren und passende Commits vorschlagen.

Workspace-Setup: Apps, Libraries, Shared Code

Ein frischer Nx-Workspace folgt einer klaren Konvention. Claude Code erkennt diese Struktur sofort und kann gezielt in einzelnen Projekten arbeiten, ohne den Rest des Workspaces zu berühren.

Terminal — Workspace initialisieren

# Neuen Nx-Workspace erstellen (React + TypeScript)
npx create-nx-workspace@latest myorg \
  --preset=react-monorepo \
  --appName=dashboard \
  --style=tailwind \
  --nxCloud=yes

# Zusätzliche App hinzufügen
nx generate @nx/react:app admin-portal \
  --directory=apps/admin-portal \
  --style=tailwind

# Shared Library anlegen
nx generate @nx/react:library ui-components \
  --directory=libs/ui-components \
  --publishable \
  --importPath=@myorg/ui-components
  

Die resultierende Ordnerstruktur ist Claude Code vertraut — es navigiert zwischen apps/, libs/ und dem Root problemlos:

myorg/
├── apps/
│   ├── dashboard/          # Haupt-App
│   └── admin-portal/       # Admin-Interface
├── libs/
│   ├── ui-components/      # Shared React Components
│   ├── data-access/        # API-Layer, Hooks
│   └── utils/              # Pure-Funktionen, Typen
├── nx.json
└── package.json
  

📦 Apps

Deployable Units. Jede App hat eigenes project.json mit Build-, Serve- und Test-Targets.

📚 Libraries

Wiederverwendbarer Code. publishable für npm, buildable für interne Nutzung — Nx verwaltet beides.

Nx Generators: Code generieren mit nx generate

Generatoren sind Nxs stärkstes Argument gegenüber Turborepo. Claude Code kann sie direkt aufrufen oder sogar eigene Workspace-Generatoren schreiben — beides ist vollständig in den Agentic-Workflow integrierbar.

Häufige Generator-Befehle

# React-Komponente in Library generieren
nx generate @nx/react:component Button \
  --project=ui-components \
  --export \
  --style=tailwind

# Feature-Slice mit Routing
nx generate @nx/react:library feature-auth \
  --directory=libs/feature-auth \
  --lazy

# Node.js API-Endpunkt
nx generate @nx/node:application api-gateway \
  --framework=fastify \
  --directory=apps/api-gateway

# Eigener Workspace-Generator
nx generate @nx/plugin:generator my-component \
  --project=workspace-plugin
  

Claude Code nutzt die --dry-run-Option, um Änderungen vor dem Ausführen zu prüfen — ein Sicherheitsnetz, das bei umfangreichen Scaffolding-Aufgaben besonders wertvoll ist.

💡 Claude Code Prompt-Pattern für Generatoren

„Erstelle eine neue feature-payments Library mit eigenem Redux-Slice, React-Hook und Jest-Tests. Nutze den Nx Generator und passe danach tsconfig.base.json automatisch an." — Claude Code führt den Generator aus, liest den Diff und ergänzt fehlende Konfiguration eigenständig.

Affected: Nur geänderte Projekte bauen und testen

Das Affected-Feature ist der Kern von Nxs CI-Effizienz. Statt alle Projekte bei jedem Push neu zu bauen, analysiert Nx den Commit-Graph und identifiziert, welche Apps und Libraries tatsächlich betroffen sind.

Affected-Commands in der Praxis

# Nur betroffene Projekte testen
nx affected --target=test --base=main --head=HEAD

# Nur betroffene Projekte bauen
nx affected --target=build --parallel=3

# Welche Projekte sind betroffen? (Übersicht)
nx affected:graph --base=main

# CI-Script: Lint + Test + Build in einem
nx affected \
  --target=lint,test,build \
  --base=origin/main \
  --parallel=4 \
  --configuration=ci
  

Affected Wie Nx den Dependency-Graph aufbaut

Nx analysiert alle import-Statements und project.json-Dependencies. Ändert sich libs/ui-components, markiert Nx alle Apps als affected, die diese Library importieren — und nur diese. Claude Code kann diesen Graph via nx graph visualisieren und in Deployment-Entscheidungen einbeziehen.

Affected in GitHub Actions

# .github/workflows/ci.yml
jobs:
  affected:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with: { fetch-depth: 0 }
      - run: npm ci
      - run: npx nx affected --target=test --base=origin/main --parallel=4
      - run: npx nx affected --target=build --base=origin/main --parallel=3
  

Remote Caching: Nx Cloud für Team-Caching

Nx Cloud speichert Build- und Test-Outputs remote — jedes Teammitglied und jede CI-Pipeline profitiert von Ergebnissen, die andere bereits berechnet haben. Das spart in großen Monorepos bis zu 80% der CI-Zeit.

Nx Cloud einrichten

# Nx Cloud verbinden (gratis bis 500 Std./Mo.)
nx connect

# nx.json — Cache-Konfiguration
{
  "nxCloudAccessToken": "${NX_CLOUD_ACCESS_TOKEN}",
  "tasksRunnerOptions": {
    "default": {
      "runner": "nx-cloud",
      "options": {
        "cacheableOperations": [
          "build", "test", "lint", "e2e"
        ],
        "parallel": 4
      }
    }
  }
}
  

Cache Hit Was gecacht wird — und was nicht

Nx hasht alle Inputs eines Targets: Quellcode, Abhängigkeiten, Umgebungsvariablen und Nx-Konfiguration. Nur wenn sich ein Input ändert, wird neu gebaut. Claude Code erkennt Cache-Misses in der Terminal-Ausgabe und kann gezielt erklären, welche Datei den Rebuild ausgelöst hat.

⚡ Lokaler Cache

In .nx/cache/ — sofort verfügbar, kein Setup. Gilt nur für deine Maschine.

☁️ Remote Cache

Nx Cloud teilt Cache zwischen allen CI-Runs und Entwicklern. Durchschnittlich 60–80% schnellere Pipelines.

Module Federation: Micro-Frontends mit Nx

Module Federation erlaubt es, mehrere unabhängig deploybare Frontends zu einem kohärenten UI zusammenzusetzen. Nx abstrahiert die komplexe Webpack-Konfiguration und bietet typsichere Remote-Imports.

Module Federation Setup

# Host-App erstellen (Shell)
nx generate @nx/react:host shell \
  --remotes=dashboard,admin-portal \
  --directory=apps/shell \
  --style=tailwind

# Remote-App hinzufügen
nx generate @nx/react:remote analytics \
  --host=shell \
  --directory=apps/analytics

# Alle Remotes gleichzeitig starten
nx serve shell --devRemotes=dashboard,analytics
  

module-federation.config.ts (Host)

import { ModuleFederationConfig } from '@nx/module-federation';

const config: ModuleFederationConfig = {
  name: 'shell',
  remotes: [
    ['dashboard', 'http://localhost:4201/'],
    ['analytics', 'http://localhost:4202/'],
  ],
  shared: (libName, defaultConfig) => {
    if (libName === 'react' || libName === 'react-dom') {
      return { ...defaultConfig, singleton: true };
    }
    return defaultConfig;
  },
};
export default config;
  

Module Federation Dynamic Federation mit Claude Code

Nxs Dynamic Federation lädt Remote-Manifeste zur Laufzeit — kein Rebuild der Shell nötig wenn sich Remote-URLs ändern. Claude Code kann das Manifest (module-federation.manifest.json) lesen, fehlende Remotes erkennen und die Konfiguration automatisch aktualisieren.

Claude Code im Nx-Workflow: Praktische Patterns

1. Dependency-Graph analysieren

Claude Code liest nx graph --file=graph.json und kann sofort erklären, welche Libraries am häufigsten importiert werden und wo potenzielle Circular-Dependency-Risiken lauern.

2. Eigene Generatoren schreiben

Wiederkehrende Scaffolding-Muster — etwa „Feature-Library mit Redux Slice, RTK Query und Tests" — lassen sich als Workspace-Generator codifizieren. Claude Code schreibt den Generator-Code und testet ihn via --dry-run.

3. Migrations automatisieren

# Nx auf neueste Version migrieren
nx migrate latest
nx migrate --run-migrations  # Codemods ausführen
  

Claude Code führt nx migrate aus, liest die generierten migrations.json und erklärt Breaking Changes auf Deutsch — ideal für Teams ohne tiefes Nx-Expertise.

4. Tags und Lint-Rules durchsetzen

# project.json — Tags für Enforcement
{
  "tags": ["scope:shared", "type:ui"]
}

# .eslintrc.json — Boundary-Regeln
{
  "@nx/enforce-module-boundaries": ["error", {
    "depConstraints": [
      { "sourceTag": "type:app", "onlyDependOnLibsWithTags": ["type:feature", "type:ui", "type:util"] },
      { "sourceTag": "type:feature", "onlyDependOnLibsWithTags": ["type:ui", "type:util"] }
    ]
  }]
}
  

Checkliste: Nx Monorepo produktionsreif

✅ Workspace-Struktur: apps/ + libs/ mit klarer Tag-Taxonomie
✅ Affected in CI: nx affected --base=origin/main in GitHub Actions
✅ Nx Cloud: Remote Cache aktiviert, Token als Secret gespeichert
✅ Boundary-Regeln: @nx/enforce-module-boundaries in ESLint konfiguriert
✅ Generatoren: Workspace-Generator für häufige Scaffolding-Patterns
✅ Module Federation: Dynamic Manifests für unabhängige Deployments
✅ Claude Code: project.json als Kontext-Anker für alle Workspace-Änderungen

Nx-Workspace mit Claude Code aufsetzen?

Starte deinen kostenlosen Trial und lass Claude Code deinen nächsten Monorepo-Workspace generieren, migrieren und skalieren — Affected Builds inklusive.

Jetzt kostenlos testen →