Prettier

Was ist Prettier?

Prettier ist ein meinungsstarker (opinionated) Code-Formatter. Er analysiert deinen Code und überführt ihn in einen Syntax-Baum, um ihn anschließend mit einem deterministischen Layout neu zu schreiben, wobei die von dir gesetzten Leerzeichen ignoriert werden. Das Ergebnis hängt ausschließlich von der Struktur des Codes und einer kleinen Anzahl an Optionen ab, sodass derselbe Input immer denselben Output erzeugt.

Genau dieser Determinismus ist der entscheidende Punkt. Diskussionen über den Coding-Style verschwinden, da der Formatter entscheidet und nicht das Team. Diffs reduzieren sich auf tatsächliche Änderungen anstatt auf unnötige Anpassungen von Abständen, sodass Reviewer ihre Zeit für Logik und Design nutzen können. Prettier ist eines der wenigen Tools, die die Reibungsverluste in einer Codebase messbar reduzieren.

Konfiguration

Prettier funktioniert auch ohne Konfiguration, aber Sie können einige Optionen in .prettierrc festlegen.

{
  "semi": true,
  "singleQuote": false,
  "trailingComma": "all",
  "printWidth": 100,
  "tabWidth": 2,
  "arrowParens": "always"
}

Dies sind die Optionen, die die meisten Teams anpassen. Darüber hinaus trifft Prettier die Entscheidungen. Je weniger Optionen Sie festlegen, desto konsistenter ist das Ergebnis über verschiedene Projekte hinweg und desto geringer ist der Wartungsaufwand.

Prettier ausführen

Dateien direkt formatieren oder prüfen, ohne Änderungen zu schreiben.

npx prettier --write .
npx prettier --check .
npx prettier --write src/app.tsx

--write formatiert die Dateien neu und speichert sie; --check meldet Dateien, die geändert würden, und beendet den Prozess mit einem Nicht-Null-Exit-Code – genau das, was für die CI benötigt wird. Füge ein Script hinzu, damit die Befehle konsistent bleiben.

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

Dateien ignorieren

.prettierignore listet Pfade auf, die übersprungen werden sollen, wobei die gleiche Syntax wie in .gitignore verwendet wird.

dist
coverage
pnpm-lock.yaml
*.generated.ts

Es ist wichtig, Build-Outputs und generierte Dateien zu ignorieren: Die Formatierung dieser Dateien erzeugt unnötiges Rauschen, das beim nächsten Build wieder überschrieben wird, und kann sogar die Codegenerierung beeinträchtigen, wenn diese ein bestimmtes Layout erwartet.

Editor-Integration

Installiere die Prettier-Extension für deinen Editor und aktiviere „Format on Save“. Hier spielt Prettier seine größte Stärke aus: Du musst dir nie wieder Gedanken über die Formatierung machen, und jeder Speichervorgang hinterlässt eine saubere Datei. Das bedeutet auch, dass du --check mit gutem Gefühl in der CI einsetzen kannst, da die Formatierung kontinuierlich erfolgt und nicht erst in einem großen Aufräumprozess am Ende.

Arbeiten mit ESLint

Prettier und ESLint überschneiden sich bei den Style-Regeln, und wenn man sie einfach so lässt, kommen sie in Konflikt. Die Standardlösung besteht darin, Prettier die Formatierung zu überlassen und die widersprüchlichen ESLint-Regeln zu deaktivieren.

// eslint.config.js
import js from "@eslint/js";
import prettier from "eslint-config-prettier";

export default [js.configs.recommended, prettier];

eslint-config-prettier schaltet jede ESLint-Regel aus, die mit Prettier kollidieren würde, sodass sich ESLint auf die Code-Qualität und Prettier auf das Layout konzentriert. Wenn Formatierungsprobleme als Lint-Fehler angezeigt werden sollen, führt eslint-plugin-prettier Prettier als Regel aus, obwohl viele Teams es bevorzugen, die beiden getrennt zu halten.

Pre-commit hooks

Die Formatierung vor einem Commit sorgt dafür, dass die CI grün bleibt und die History sauber ist.

{
  "lint-staged": {
    "*.{js,jsx,ts,tsx,css,md}": "prettier --write"
  }
}

In Kombination mit einem Hook-Runner wie husky werden so nur die gestagten Dateien formatiert, sodass die Commits schnell bleiben. Dieser geringe Setup-Aufwand verhindert eine ganze Kategorie von Review-Kommentaren bezüglich „unformatiertem Code“.

Wo Prettier ins Spiel kommt

Prettier ist ausschließlich für das Formatting zuständig. Es findet keine Bugs, erzwingt keine Typen und prüft keine Imports – das sind Aufgaben von ESLint und dem Type Checker. Eine solide Toolchain nutzt alle drei: Prettier für das Layout, ESLint für die Qualität und TypeScript für die Typen. Jedes Tool hat eine spezifische Aufgabe, und sie stehen nicht im Konflikt zueinander.

Best Practices

• Akzeptieren Sie die Standardwerte, es sei denn, Ihr Team hat einen triftigen Grund, einen davon zu ändern.
• Committen Sie eine .prettierrc, damit jeder Editor und jeder CI-Run konsistent bleiben.
• Fügen Sie .prettierignore für Build-Outputs und generierte Dateien hinzu.
• Nutzen Sie „Format on Save“ in Ihrem Editor.
• Führen Sie --check in der CI und --write in einem Pre-Commit-Hook aus.
• Deaktivieren Sie widersprüchliche ESLint-Regeln mit eslint-config-prettier.
• Halten Sie die Liste der Optionen kurz.

Häufige Fehler

• ESLint und Prettier gleichzeitig formatieren lassen, was zu Konflikten führt.
• Generierte Dateien formatieren und dadurch unnötig große Diffs erzeugen.
• Den CI-Check überspringen, sodass unformatierter Code gemergt wird.
• Optionen pro Projekt ohne Grund ändern und dadurch die Konsistenz zwischen Projekten verlieren.
• Prettier in einem pre-commit hook über das gesamte Repo laufen lassen und so Commits verlangsamen.
• Prettier nutzen, um semantische Regeln zu erzwingen, die eigentlich in ESLint gehören.

Wie geht es weiter?

Prettier nimmt euch eine ganze Kategorie von mühsamer Routinearbeit ab. Kombiniert es mit ESLint für die Code-Qualität, TypeScript für Typsicherheit und bindet beides in euer Vite-Projekt sowie in die CI ein. Richtet anschließend „Format on Save“ ein und ihr müsst euch nie wieder Gedanken über Abstände machen.