Prettier mit Claude Code konfigurieren

Wenn Claude Code echte Änderungen in einem Repository übernimmt, ist Formatierung kein Nebenthema mehr. Eine kleine Aufgabe kann Komponenten, Tests, JSON, Markdown und CI-Konfiguration gleichzeitig berühren. Wenn dabei Einrückung, Anführungszeichen, Zeilenumbrüche und trailing commas in einem Diff durcheinander geraten, wird Review-Arbeit unnötig schwer.

Prettier ist ein Code-Formatter. Das bedeutet: Prettier bringt die äußere Form unterstützter Dateien in eine einheitliche Struktur, ohne über die fachliche Logik zu urteilen. Diese Trennung ist wichtig. Prettier kümmert sich um Layout, während Tests, TypeScript und ESLint Verhalten und Qualitätsregeln prüfen.

Dieser Leitfaden zeigt eine praxistaugliche Prettier-Konfiguration für Claude Code. Enthalten sind lokale Installation, .prettierrc, .prettierignore, npm scripts, VS Code Settings, CI-Check, staged formatting und Projektanweisungen, damit Claude Code die Regeln respektiert. Die Beispiele passen zu typischen npm-Projekten mit JavaScript oder TypeScript.

Überblick

Prettier sollte nicht nur ein Aufräumkommando am Ende sein. Besser ist ein kleiner Qualitätsmechanismus an mehreren Stellen im Workflow.

flowchart LR
  A["Claude Code bearbeitet Dateien"] --> B[".prettierrc definiert Regeln"]
  B --> C["VS Code formatiert beim Speichern"]
  C --> D["npm run format:check"]
  D --> E["lint-staged formatiert staged files"]
  E --> F["CI prüft den Pull Request"]

Jede Ebene hat eine klare Aufgabe. .prettierrc enthält die Formatierungsregeln. .prettierignore schützt generierte oder irrelevante Dateien. package.json scripts geben Menschen, Claude Code und CI dieselben Befehle. VS Code liefert schnelles Feedback beim Arbeiten. lint-staged begrenzt Änderungen auf Commit-Dateien. CI verhindert, dass unformatierter Code in die Review gelangt.

Claude Code kann natürlich Anweisungen im Prompt befolgen. Für wiederholbare Arbeit sollten Formatierungsregeln aber im Repository liegen, nicht nur im Gesprächsverlauf.

Prettier lokal installieren

Installiere Prettier als lokale Development Dependency. Die offizielle Anleitung Prettier Install empfiehlt lokale Installation mit exakter Version, damit alle Umgebungen dasselbe Formatter-Verhalten nutzen.

npm install --save-dev --save-exact prettier

Beim ersten Einführen kannst du einmal das ganze Projekt formatieren.

npx prettier . --write

In einem bestehenden Projekt sollte diese erste Formatierung ein eigener Commit oder Pull Request sein. Vermische eine repo-weite Formatter-Änderung nicht mit einer Feature-Änderung. Sonst versteckt der mechanische Diff die eigentliche Arbeit und erschwert spätere Fehlersuche.

.prettierrc anlegen

Prettier unterstützt mehrere Konfigurationsformen, darunter .prettierrc, prettier.config.mjs und einen prettier-Eintrag in package.json. Die offizielle Dokumentation zu Configuration File erklärt, dass Prettier vom formatierten Dateiort nach oben sucht und bewusst keine globale Konfiguration verwendet. Dadurch bleibt das Ergebnis zwischen Maschinen reproduzierbar.

Für den Start ist eine JSON-basierte .prettierrc gut lesbar.

{
  "printWidth": 100,
  "tabWidth": 2,
  "useTabs": false,
  "semi": true,
  "singleQuote": false,
  "trailingComma": "all",
  "bracketSpacing": true,
  "bracketSameLine": false,
  "arrowParens": "always",
  "endOfLine": "lf",
  "overrides": [
    {
      "files": "*.md",
      "options": {
        "proseWrap": "always"
      }
    },
    {
      "files": ["*.yml", "*.yaml"],
      "options": {
        "singleQuote": false
      }
    }
  ]
}

printWidth ist kein hartes Zeichenlimit, sondern ein Hinweis für Prettiers Umbruchentscheidung. endOfLine: "lf" reduziert Unterschiede zwischen Windows, macOS, Linux und CI. trailingComma: "all" sorgt oft für kleinere Diffs, wenn später Elemente in Objekten oder Arrays ergänzt werden.

Wenn dein Projekt stark auf Tailwind CSS setzt, kann prettier-plugin-tailwindcss sinnvoll sein. Füge Plugins aber nicht zu früh hinzu. Stabilisiere zuerst die Grundformatierung, dann erweitere gezielt.

.prettierignore definieren

.prettierignore sagt Prettier, welche Dateien nicht formatiert werden sollen. Das betrifft Build-Artefakte, Caches, generierten Code, minifizierte Dateien und Lockfiles, die von anderen Tools verwaltet werden.

node_modules
dist
build
coverage
.next
.nuxt
.astro
.vercel
.cache
*.min.js
package-lock.json
pnpm-lock.yaml
yarn.lock

Prettier berücksichtigt auch .gitignore, wenn es aus demselben Verzeichnis läuft. Trotzdem haben beide Dateien unterschiedliche Aufgaben. .gitignore entscheidet, was Git verfolgen soll. .prettierignore entscheidet, was Prettier nicht umschreiben soll. Diese Grenze hilft auch Claude Code, generierte Bereiche nicht versehentlich anzufassen.

Ein typischer Fehler ist vergessener generierter API-Code. Claude Code ändert eine kleine Komponente, danach formatiert prettier . --write plötzlich tausende Zeilen unter src/generated/. Generierten Code sollte man über das Schema oder die Quelle ändern und dann neu generieren, nicht im Feature-Diff verstecken.

npm scripts hinzufügen

Die offiziellen npm-Dokumente beschreiben scripts als Ort für ausführbare Projektbefehle. In einem Claude-Code-Workflow sind diese Namen wichtig, weil Agent, Entwickler und CI dieselben Kommandos verwenden können.

{
  "scripts": {
    "format": "prettier . --write",
    "format:check": "prettier . --check"
  }
}

Lokal nutzt du den Schreibbefehl, in Automatisierung den Check.

npm run format
npm run format:check

format verändert Dateien. format:check prüft nur, ob alles bereits formatiert ist, und schlägt sonst fehl. Für CI ist format:check deshalb klarer: Der Build meldet das Problem, ohne ungeprüften Code umzuschreiben.

VS Code konfigurieren

Formatierung beim Speichern verhindert viel Rauschen vor dem Commit. Lege die Einstellung in .vscode/settings.json ab, damit das Repository die Konvention trägt und nicht jede Person eigene Editorregeln pflegen muss.

{
  "editor.defaultFormatter": "esbenp.prettier-vscode",
  "editor.formatOnSave": true,
  "prettier.requireConfig": true,
  "[javascript]": {
    "editor.defaultFormatter": "esbenp.prettier-vscode"
  },
  "[typescript]": {
    "editor.defaultFormatter": "esbenp.prettier-vscode"
  },
  "[typescriptreact]": {
    "editor.defaultFormatter": "esbenp.prettier-vscode"
  },
  "[json]": {
    "editor.defaultFormatter": "esbenp.prettier-vscode"
  },
  "[mdx]": {
    "editor.defaultFormatter": "esbenp.prettier-vscode"
  }
}

prettier.requireConfig ist eine nützliche Sicherung. Die Extension formatiert dann nur Projekte, die bewusst eine Prettier-Konfiguration haben. Wer häufig zwischen Repositories wechselt, vermeidet dadurch ungewollte Änderungen.

Formatierung in CI prüfen

Ein minimales GitHub-Actions-Setup reicht für den Anfang.

name: format

on:
  pull_request:
  push:
    branches: [main]

jobs:
  prettier:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 22
          cache: npm
      - run: npm ci
      - run: npm run format:check

Wenn Claude Code Pull Requests aktualisiert, verhindert dieser Check mechanischen Review-Lärm. Für weitere Qualitätsregeln kombiniere ihn mit dem Claude Code ESLint Guide, aber halte Formatter- und Linter-Signale getrennt.

Nur staged files formatieren

In großen Repositories kann eine vollständige Formatierung bei jedem Commit langsam sein und alte Formatierungsprobleme anfassen. Husky und lint-staged formatieren nur Dateien, die bereits mit git add ausgewählt wurden. Der gesamte Git-Hook-Workflow steht im Husky + lint-staged Guide, hier ist die Minimalvariante.

npm install --save-dev --save-exact husky lint-staged
npm pkg set scripts.prepare="husky"
npx husky init

Ergänze package.json so:

{
  "scripts": {
    "prepare": "husky"
  },
  "lint-staged": {
    "*.{js,jsx,ts,tsx,css,md,mdx,json,yml,yaml}": "prettier --write"
  }
}

.husky/pre-commit bleibt einfach.

npx lint-staged

Der Vorteil ist die Kontrolle über den Umfang. Wenn Claude Code drei Dateien ändert, formatiert der Pre-Commit-Schritt diese drei Dateien und nicht das gesamte Repository.

Claude Code die Regeln geben

Projektregeln gehören in CLAUDE.md. Die offizielle Claude Code memory documentation beschreibt ./CLAUDE.md und ./.claude/CLAUDE.md als geteilte Projektanweisungen für Befehle, Coding Standards und Workflows.

## Formatting

- Read `.prettierrc` and `.prettierignore` before formatting files.
- Do not reformat unrelated files while implementing a feature.
- After changing JavaScript, TypeScript, CSS, Markdown, JSON, or YAML, run `npm run format:check`.
- Keep formatter-only changes separate from behavior changes.

Mehr Automatisierung ist mit Claude Code hooks möglich. Der offizielle hooks guide zeigt ein Beispiel, das nach Edit oder Write Prettier ausführt.

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Edit|Write",
        "hooks": [
          {
            "type": "command",
            "command": "jq -r '.tool_input.file_path' | xargs npx prettier --write"
          }
        ]
      }
    ]
  }
}

Dieser Hook ist nützlich, hängt aber von jq und Shell-Verhalten ab. In Windows-lastigen Teams ist es oft robuster, zunächst klare CLAUDE.md-Anweisungen und npm run format:check am Ende jeder Aufgabe zu nutzen. Den Hook teilt man erst, wenn die Umgebung überall gleich funktioniert.

Drei Anwendungsfälle

Anwendungsfall	Nutzen von Prettier	Anweisung an Claude Code
TypeScript-Produkt-App	Komponenten, Tests und Typ-Utilities bleiben in einem lesbaren Diff	Führe nach der Änderung npm run format:check aus.
Astro- oder MDX-Site	Frontmatter, Markdown, Code-Fences und JSON bleiben einheitlich	Prüfe, dass die MDX code fences gültig bleiben.
Team-Pull-Requests	Review konzentriert sich auf Verhalten statt Einrückung	Vermische reine Formatierungsänderungen nicht mit dem Feature.

Besonders deutlich ist der Effekt bei MDX. Eine Datei kann Text, Frontmatter, Shell-Befehle, JSON und JSX enthalten. Ohne Prettier erzeugt Claude Code manchmal fachlich korrekten, aber visuell unruhigen Inhalt. Mit gemeinsamer Formatierung geht die Review wieder um Genauigkeit und ausführbare Beispiele.

Häufige Fehler

Der erste Fehler ist npx prettier . --write ohne installierte Dependency. Wenn Prettier nicht in devDependencies fixiert ist, kann später eine andere Version laufen. Installiere lokal mit --save-exact.

Der zweite Fehler ist Konkurrenz zwischen ESLint und Prettier. Prettier formatiert. ESLint prüft mögliche Bugs und Wartbarkeit. Wenn Style-Regeln kollidieren, hilft oft eslint-config-prettier.

Der dritte Fehler ist eine komplette Repository-Formatierung in einem Feature-Branch. Wenn die Basis uneinheitlich ist, erstelle zuerst einen Formatter-only-Change. Danach sollte Claude Code keine nicht verwandten Dateien formatieren.

Der vierte Fehler ist ein zu breites .prettierignore. Ein Eintrag wie src/** entfernt den wichtigsten Code aus der Formatierung. Ignoriere generierte Dateien, Caches, große Artefakte und externe Tool-Ausgaben, nicht den täglich reviewten Code.

Monetarisierungs-CTA

Wenn du Claude Code in mehreren Projekten nutzt, ist nicht nur .prettierrc wiederverwendbar. Wertvoll ist das Betriebssystem darum herum: CLAUDE.md, Prüfkommandos, Review-Checklisten, PR-Templates und Handoff-Regeln. ClaudeCodeLab sammelt solche Vorlagen auf der Produktseite, damit diese Konfiguration zu einem wiederholbaren Teamstandard wird.

Fazit

Prettier ist eine kleine, aber wichtige Grundlage für Claude Code. Installiere es lokal, definiere .prettierrc, schütze generierte Dateien mit .prettierignore, stelle format und format:check bereit, nutze VS Code für direktes Feedback, prüfe in CI und setze lint-staged für Commit-Umfang ein. Dokumentiere dieselbe Erwartung anschließend in CLAUDE.md.

Getestetes Ergebnis: Nach der Anwendung auf ein kleines TypeScript- und MDX-Projekt erzeugte die erste Formatierung eine saubere Basis. Danach lief npm run format:check stabil, und von Claude Code erzeugte Artikeländerungen waren leichter zu prüfen. Am meisten halfen das Ignorieren generierter Ausgaben und die Trennung von format und format:check.