ESLint und Prettier Konflikt lösen: So geht es

Warum entsteht ein Eslint und Prettier Konflikt?

Ein Eslint und Prettier Konflikt entsteht, wenn zwei Werkzeuge unterschiedliche Entscheidungen über denselben Code treffen. Eslint will eine bestimmte Einrückung oder Anführungszeichen. Prettier schreibt die Datei beim Speichern in eine andere Form um. Der Editor füllt sich mit widersprüchlichen Warnungen.

Das passiert vor allem, wenn Sie beide Werkzeuge unabhängig voneinander einrichten. Eslint prüft die Codequalität und findet echte Fehler. Prettier entscheidet dagegen automatisch über Abstände, Zeilenumbrüche und Anführungszeichen. Sobald beide Werkzeuge über dieselbe Formatentscheidung streiten, erzeugt jedes Speichern eine neue Warnungswelle. Die Ursache ist fast immer eine fehlende Aufgabentrennung zwischen beiden Werkzeugen.

Dieses Problem löst sich nie von selbst. Es kehrt bei jedem Speichern, jedem Commit und jeder Code Review zurück. Mit der Zeit ignorieren Teams die Warnungen einfach. Schließlich übersehen sie dadurch auch einen echten Fehler.

Zum Beispiel ignoriert ein Team manchmal Dutzende Stilwarnungen jeden einzelnen Tag. Außerdem denkt ein neuer Mitwirkender bei so vielen roten Markierungen oft, das Projekt sei grundsätzlich kaputt. Daher lohnt es sich, die Ursache früh und gründlich zu beheben.

Was macht Eslint genau?

Eslint ist ein statisches Analysewerkzeug für JavaScript und TypeScript. Es findet ungenutzte Variablen, unerreichbaren Code und riskante Vergleiche frühzeitig. Außerdem hilft es einem Team, gemeinsame Konventionen durchzusetzen, zum Beispiel Namensregeln oder vorgeschriebene Funktionsmuster.

Dank seines Plugin Ökosystems fügen Sie Regeln für React, Vue oder Node.js hinzu. Deshalb geht Eslint weit über reine Formatierung hinaus. Warum stört ein so breites Regelwerk dann die Zusammenarbeit mit Prettier? Weil einige Stilregeln sich mit Entscheidungen überschneiden, die Prettier bereits automatisch trifft.

Die Einrückung ist ein gutes Beispiel. Will Eslint eine Breite und Prettier eine andere, wird daraus Lärm in der ganzen Datei. Bei einer großen Datei betrifft das fast jede Zeile, und echte Fehler gehen im Rauschen unter. Zum Beispiel erzeugt eine einzige falsche Einrückungseinstellung oft Hunderte Warnungen in einem einzigen Pull Request. Folglich verbringen Reviewer Zeit mit Scrollen statt mit dem eigentlichen Logikwechsel. Deshalb lohnt es sich, diesen Punkt schon vor dem ersten Release zu klären, statt ihn auf später zu verschieben.

Was macht Prettier genau?

Prettier ist ein Formatierer, der den Stil nach einer einzigen festen Regel neu schreibt. Sie entscheiden Einrückung, Anführungszeichen und Kommas nicht mehr selbst. Prettier formatiert die Datei im Moment des Speicherns neu. Das Ziel ist, Stildebatten im Team komplett zu beenden.

Dieser Ansatz spart Zeit in der Code Review, denn niemand kommentiert mehr Anführungszeichen. Außerdem bleibt die Ausgabe gleich, egal welchen Editor jeder Entwickler nutzt. Allerdings betrachtet Prettier nie die Logik, sondern nur das Aussehen. Deshalb übernimmt Prettier auch nicht die Qualitätsprüfung von Eslint.

Manche Entwickler behandeln Prettier nur als persönliche Vorliebe statt als Teamstandard. Sobald ein Projekt wächst, erzeugt genau diese Gewohnheit unnötige Unterschiede in jedem einzelnen Commit. Ein verbindlicher Standard ab dem ersten Tag hält die Historie dagegen sauber. Sonst wendet jeder Mitwirkende einen leicht anderen Stil an, und genau das zeigt sich in fast jedem Diff. In der Praxis ist das einer der einfachsten Erfolge, die ein Team früh sichern kann.

Warum nutzen Teams Eslint und Prettier zusammen?

Die meisten Teams wollen sowohl Fehlerprüfung als auch einheitliche Formatierung. Deshalb setzen sie beide Werkzeuge gleichzeitig ein. Eslint schützt die Codequalität, während Prettier Stildebatten beendet. Diese Kombination ist auf größeren Projekten mit vielen Mitwirkenden fast schon Standard.

Beide Werkzeuge einfach nebeneinander zu betreiben garantiert aber keine Harmonie. Jedes Werkzeug bringt eigene Formatannahmen mit. Weichen diese voneinander ab, sammeln sich Konflikte leise an. Mit wachsendem Projekt sieht jeder Entwickler nach jedem Speichern eine neue Liste von Warnungen.

Sobald Sie sich für beide Werkzeuge entscheiden, gehört das Kompatibilitätspaket von Anfang an auf Ihre Einrichtungsliste. Sonst sammelt sich der Konflikt schon ab dem ersten Tag des Projekts an. Zum Beispiel verbringen Teams, die mehrere Monate warten, danach oft einen ganzen Sprint nur mit dem Aufräumen angesammelter Warnungen. Deshalb ist es immer günstiger, dies von Anfang an korrekt einzurichten.

Welche Regeln verursachen den Konflikt meist?

Konflikte treten meist bei Einrückung, Anführungszeichen, Kommas am Zeilenende und maximaler Zeilenlänge auf. Stimmen die eigenen Stilregeln von Eslint nicht mit dem überein, was Prettier anwendet, entsteht bei jedem Speichern eine neue Fehlerliste. Die Regel indent ist ein klassisches Beispiel dafür, und die offizielle Dokumentation von eslint-config-prettier nennt sie ausdrücklich.

• Breite und Art der Einrückung, etwa Leerzeichen oder Tabs.
• Bevorzugte Anführungszeichen, einfach oder doppelt.
• Kommas am Ende einer Zeile.
• Regeln zur maximalen Zeilenlänge.

Diese Liste wächst mit dem Projekt weiter. Statt jede Regel einzeln zu jagen, blockieren Sie den Konflikt also besser direkt an der Quelle.

Was macht das Paket Eslint Config Prettier?

Statt widersprüchliche Regeln einzeln abzuschalten, empfiehlt die offizielle Prettier Dokumentation das Paket eslint-config-prettier. Es schaltet jede Stilregel von Eslint ab, die mit Prettier kollidieren könnte. Die Formatierung gehört dann vollständig Prettier, während Eslint sich auf die Codequalität konzentriert.

Das Paket berücksichtigt auch mehrere Plugin Regelwerke, zum Beispiel von TypeScript, React oder Vue. Mit anderen Worten: eine kleine Konfigurationsergänzung schließt viele mögliche Konfliktpunkte gleichzeitig. Dieser Schutz funktioniert sogar dann noch weiter, wenn Sie später neue Plugins hinzufügen.

Ein Detail ist wichtig: das Paket schaltet nur Regeln ab. Es fügt selbst keine Formatregeln hinzu. Deshalb kombinieren Sie es immer mit einer anderen Eslint Konfiguration als Basis. Manche Entwickler denken fälschlicherweise, das Paket funktioniere nicht, sobald nach der Installation noch einzelne Warnungen übrig bleiben. In Wirklichkeit sind diese verbleibenden Warnungen meist echte Qualitätsprobleme, denn das Paket schaltet ausschließlich Stilregeln ab und rührt die Logik nicht an.

Wie installieren Sie Eslint Config Prettier?

Die Installation braucht nur einen Befehl: npm i -D eslint-config-prettier. Nach der Installation fügen Sie das Paket Ihrer Eslint Konfiguration hinzu. In einer klassischen .eslintrc Datei setzen Sie "prettier" ans Ende des Arrays extends. So überschreibt es jede widersprüchliche Regel davor.

Nutzen Sie die neue Flat Config, also eslint.config.js, importieren Sie stattdessen eslint-config-prettier/flat. Platzieren Sie es ans Ende des Arrays. Die Reihenfolge ist hier entscheidend: steht es am Anfang, aktivieren spätere Einträge die gerade abgeschalteten Regeln erneut.

Nach der Installation prüfen Sie das Projekt einmal von vorne bis hinten. Die meisten alten, widersprüchlichen Warnungen verschwinden sofort. Was übrig bleibt, ist ein echtes Qualitätsproblem, keine Stilfrage mehr. In der Praxis entfernt dieser einzelne Durchgang oft den Großteil der offenen Warnungen eines Projekts auf einmal.

Sollten Sie Eslint Plugin Prettier trotzdem nutzen?

Manche Teams greifen zu eslint-plugin-prettier, das Prettier wie eine Eslint Regel ausführt. Die offizielle Dokumentation empfiehlt diesen Weg heute allgemein nicht mehr. Er zeigt Formatunterschiede als rote Schlangenlinien an, und das überflutet den Editor mit unnötigem Rauschen.

Außerdem läuft diese Schicht langsamer als Prettier direkt, und die zusätzliche Ebene kann eigene Probleme verursachen. Dieses Plugin war in den frühen Jahren von Prettier sinnvoll. Heute liefert die Trennung von Lint und Format in eigene Befehle ein einfacheres und schnelleres Ergebnis.

Die offizielle Dokumentation nennt außerdem prettier-eslint und prettier-stylelint. Diese helfen in seltenen Fällen, in denen die Ausgabe von Prettier allein nicht nutzbar ist. Sie führen zuerst Prettier aus und wenden danach verbleibende Eslint Regeln an. Allerdings laufen sie viel langsamer als Prettier allein. Probieren Sie daher zunächst das Standardpaket, und greifen Sie nur bei echtem Bedarf zu diesen zusätzlichen Werkzeugen. Sonst riskieren Sie eine langsamere, schwerere Abhängigkeit für ein Problem, das die einfachere Lösung bereits löst.

Gibt es einen Unterschied zwischen Eslintrc und Flat Config?

Ja, beide Konfigurationsformate funktionieren unterschiedlich. Sie fügen eslint-config-prettier in jedem Format anders ein. Die alte .eslintrc.* Datei arbeitet mit dem Array extends. Die neue Flat Config ist dagegen als einfaches JavaScript Array definiert; der offizielle Eslint Konfigurationsleitfaden beschreibt beide Formate ausführlich.

Klären Sie deshalb zuerst, welches Format Ihr Projekt tatsächlich nutzt. In einem gemischten Setup, in dem beide Formate noch parallel existieren, landet das Paket oft an der falschen Stelle. Der Konflikt kehrt dann immer wieder zurück. Da aktuelle Eslint Versionen zur Flat Config tendieren, starten neue Projekte meist besser direkt dort.

Migrieren Sie ein bestehendes Projekt, aktualisieren Sie die Konfiguration schrittweise. Das ist sicherer, als alle Regeln gleichzeitig umzuschreiben. In der Praxis entdecken Teams, die ein Paket nach dem anderen migrieren, Fehler frühzeitig, bevor sie sich im ganzen Repository ausbreiten.

Warum führen Sie Lint und Format getrennt aus?

Die offizielle Prettier Quelle empfiehlt, Lint und Formatierung als zwei getrennte Befehle auszuführen. So erledigt jedes Werkzeug seine eigene Aufgabe: Eslint findet Logikfehler, Prettier regelt das Format. Diese Trennung erleichtert außerdem die Fehlersuche, denn Sie wissen sofort, welches Werkzeug verantwortlich ist.

Zum Beispiel prüft prettier --check . die Formatierung als eigenen Schritt. Die meisten Editoren führen Prettier zudem automatisch beim Speichern aus. Formatprobleme sind dadurch meist schon vor einem Commit gelöst.

Sobald diese Trennung zur Gewohnheit wird, ändert sich die ganze Teamdiskussion. Niemand streitet mehr über Anführungszeichen. Jedes Gespräch dreht sich stattdessen sofort um die eigentliche Logik.

Wie finden Sie widersprüchliche Regeln?

Das Paket eslint-config-prettier bringt dafür einen Hilfsbefehl mit: npx eslint-config-prettier path/to/main.js. Findet der Befehl einen Konflikt, endet er mit einem anderen Statuscode. Außerdem listet er genau die betroffenen Regeln auf.

Führen Sie diesen Schritt bei einem neuen Projekt oder beim Aktualisieren einer bestehenden Konfiguration aus. Er erspart Ihnen den manuellen Vergleich jeder einzelnen Regel. Außerdem lohnt sich eine erneute Prüfung, sobald Sie ein neues Plugin hinzufügen, denn so finden Sie einen übersehenen Konflikt frühzeitig. Zudem lässt sich dieser Befehl problemlos in ein Skript Ihres Paketmanagers einbauen, sodass das ganze Team dieselbe Prüfung mit einer einzigen Zeile ausführt.

Worauf achten Sie bei der Editor Integration?

Sind sowohl die Eslint als auch die Prettier Erweiterung gleichzeitig aktiv, wird das schnell verwirrend. Das sauberste Setup überlässt die Formatierung beim Speichern vollständig Prettier. Eslint bleibt dagegen für Fehler und Qualitätsprüfung zuständig.

Wichtig ist außerdem, dass im Team alle dieselben Editoreinstellungen verwenden. Sonst speichert der Editor einer Person den Code anders als der einer anderen Person. Eine gemeinsame Einstellungsdatei im Projektstamm beseitigt diesen Unterschied vollständig.

Manche Teams legen das in einer gemeinsamen Editorkonfigurationsdatei im Stammverzeichnis fest. Andere dokumentieren es nur und hoffen, dass jeder Entwickler es manuell übernimmt. Der erste Weg ist deutlich zuverlässiger. Ein neues Teammitglied übernimmt die richtigen Einstellungen dann automatisch beim Klonen. Zudem entfällt dadurch jede zusätzliche Erklärung in einem separaten Einrichtungsdokument, denn die Konfiguration spricht praktisch für sich selbst.

Wie setzen Sie einen gemeinsamen Teamstandard durch?

Bei mehreren Mitwirkenden hängt ein gemeinsamer Standard von Konfigurationsdateien im Projektstamm ab, nicht von persönlichen Vorlieben. Sobald die Einstellungen von Eslint und Prettier in der Versionskontrolle liegen, übernimmt jeder Mitwirkende automatisch dieselben Regeln.

Das beseitigt Kommentare wie "bitte die Anführungszeichen ändern" komplett aus der Code Review. Ein neuer Entwickler übernimmt ebenfalls sofort die richtige Einrichtung beim Klonen. Eine separate Anleitung braucht niemand mehr. Das Team steckt seine Energie dann in echte Codequalität statt in Stildebatten. In der Praxis spart genau diese eine Entscheidung dem Team jede Woche mehrere Diskussionen in der Code Review.

Kunden, die diesen Schritt früh überspringen, sammeln nach Monaten oft Hunderte Warnungen an. Das Aufräumen dauert dann deutlich länger, als die richtige Einrichtung in der ersten Woche gedauert hätte.

Wie prüfen Sie die Formatierung in einer CI/CD Pipeline?

Fügen Sie die Prüfungen von Eslint und Prettier als getrennte Schritte in Ihre Pipeline ein. Das verhindert, dass schlecht formatierter Code in den Hauptzweig gelangt. Eine typische Pipeline folgt diesen Schritten:

1. Abhängigkeiten installieren, zum Beispiel mit pnpm install.
2. eslint . ausführen, um die Codequalität zu prüfen.
3. prettier --check . ausführen, um die Formatierung zu prüfen.
4. Den Merge erst erlauben, wenn beide Schritte erfolgreich sind.

Bleiben diese zwei Schritte getrennt, sehen Sie sofort, welche Prüfung fehlschlägt. Liegt ein Formatfehler vor, behebt ein Entwickler ihn mit nur einem Befehl über Prettier. Die Pipeline wird so zu zwei unabhängigen Toren, eines für Qualität und eines für Konsistenz.

Steigt das Konfliktrisiko in Monorepo Projekten?

Ja, das Risiko steigt in einem Monorepo, in dem mehrere Pakete in einem Repository liegen. Jedes Paket kann seine eigene Eslint Konfiguration mitbringen. Mit der Zeit können diese Konfigurationen auseinanderlaufen. Eine gemeinsame Konfigurationsdatei im Stammverzeichnis macht hier einen echten Unterschied.

Nutzen Sie pnpm oder npm Workspaces, prüfen Sie zudem, ob der Abhängigkeitsbaum für jedes Paket dieselbe Werkzeugversion auflöst. Sonst läuft ein Paket auf einer alten Eslint Version, während ein anderes eine neuere nutzt. Das Verhalten weicht dann zwischen den Paketen ab.

Diese Prüfung bei Dutzenden Paketen von Hand vorzunehmen ist unpraktisch. Deshalb legen die meisten Teams eine einzige Kompatibilitätskonfiguration im Stammverzeichnis ab und lassen jedes Paket sie erben. Fügen Sie ein neues Paket hinzu, verweisen Sie am besten darauf, statt sie zu kopieren. So aktualisieren Sie künftig alles von einer einzigen Stelle aus.

Welche Fehler verursachen den Eslint und Prettier Konflikt oft?

Der häufigste Fehler ist, beide Werkzeuge zu installieren und nie ein Kompatibilitätspaket wie eslint-config-prettier hinzuzufügen. In diesem Fall bekämpfen sich beide Werkzeuge endlos. Ein weiterer häufiger Fehler ist, die Kompatibilitätskonfiguration an den Anfang des Arrays extends zu setzen. Das nimmt ihr die Fähigkeit, überhaupt etwas zu überschreiben. Ebenso häufig bleibt ein Projekt auf halbem Weg zwischen altem und neuem Konfigurationsformat stehen, was den Konflikt zuverlässig zurückbringt.

• Das Kompatibilitätspaket überhaupt nicht installieren.
• Die Kompatibilitätskonfiguration an den Anfang der Liste setzen.
• Altes und neues Konfigurationsformat halb migriert lassen.
• Editoreinstellungen nie im Team teilen.

Jeder dieser Fehler wirkt für sich klein. Zusammen zehren sie aber deutlich an der Geduld der Entwickler.

Ein weniger offensichtlicher Fehler ist, jede Warnung einzeln per Hand zu lösen. Manche Entwickler schließen eine Warnung nach der anderen von Hand. Dieser Ansatz skaliert nicht mehr, sobald das Projekt wächst. Ebenso taucht dasselbe Problem dann in jeder neuen Datei wieder auf. Die korrekte Installation des Kompatibilitätspakets beseitigt diese sich wiederholende Arbeit endgültig. Zusammengefasst lohnt sich diese einmalige Investition deutlich mehr als jede wiederholte Handarbeit an denselben Warnungen. Außerdem bleibt dem Team dadurch mehr Zeit für echte Architekturfragen.

Was ändert sich, sobald der Konflikt gelöst ist?

Sobald der Konflikt gelöst ist, verschwinden die unnötigen roten Warnungen. Jedes Speichern erzeugt dann ein einziges, einheitliches Format. Entwickler verlieren keine Zeit mehr mit Stildebatten. Stattdessen lenken sie diese Energie auf echte Logik und echte Codequalität.

Auch die Code Review wird kürzer, denn Kommentare zum Format fallen vollständig weg. Neue Entwickler kommen ebenfalls schneller voran, weil die Werkzeuge bereits automatisch einen einheitlichen Standard durchsetzen.

Viele Teams merken den Unterschied auch jenseits des Editors. Die Bearbeitungszeit von Pull Requests sinkt, weil sich das Gespräch direkt auf Architektur und Logik verlagert. Das beschleunigt indirekt die gesamte Lieferzeit. Auf lange Sicht summiert sich diese kleine Gewohnheit über Dutzende Pull Requests im Monat.

Wer sollte dieses Setup bei individuellen Softwareprojekten übernehmen?

Diese Werkzeugabstimmung schon zu Beginn eines individuellen Projekts richtig einzurichten, erspart später viel verlorene Zeit. Unser Team behandelt diese Art von Konfiguration als festen Schritt am Anfang jedes Projekts zur individuellen Softwareentwicklung.

Dieser Ansatz garantiert, dass jeder später dazukommende Entwickler nach demselben Standard arbeitet. Wächst das Projekt, kehren Werkzeugkonflikte deshalb nicht zurück, weil die Grundlage von Anfang an richtig eingerichtet wurde. Konkret bedeutet das für Kunden weniger Nachfragen und eine deutlich kürzere Einarbeitungszeit für jeden neuen Entwickler im Team. Zudem sinkt dadurch auch das Risiko kleiner, unnötiger Reibungen im Alltag spürbar.

Fazit: Wie lösen Sie einen Eslint und Prettier Konflikt dauerhaft?

Einen Eslint und Prettier Konflikt dauerhaft zu lösen bedeutet, die Aufgabenteilung klar zu halten. Die Formatierung gehört Prettier. Die Codequalität gehört Eslint. Fügen Sie eslint-config-prettier an der richtigen Stelle ein, bleibt diese Trennung automatisch erhalten.

Richten Sie es einmal korrekt ein, kehrt das Team nie wieder zu Stildebatten zurück. Dieser kleine, aber dauerhafte Schritt verbessert die Entwicklererfahrung für die gesamte Lebensdauer des Projekts. Der Zeitaufwand der Einrichtung zahlt sich schon in den ersten Wochen aus. Zusammengefasst lohnt sich diese kleine Investition für jedes Projekt, unabhängig von seiner Größe.

Wie vergleichen Sie Eslint und Prettier auf einen Blick?

Die folgende Tabelle zeigt, wo die Verantwortung jedes Werkzeugs endet. Das macht die Quelle des Konflikts leichter erkennbar.

Welche verwandten Werkzeuge kombinieren Sie meist mit diesem Setup?

Die Einrichtung von Eslint und Prettier hängt oft auch von der Wahl des Paketmanagers ab. Für eine schnellere Abhängigkeitsauflösung hilft unser Beitrag Was ist pnpm. Tauchen beim Setup Fehler im Abhängigkeitsbaum auf, hilft unser Beitrag npm eresolve Fehler lösen direkt weiter.

Bewegt sich Ihr Projekt in Richtung TypeScript, unterstützt unser Vergleich TypeScript gegen JavaScript bei dieser Entscheidung. Für verwandte Interviewfragen lohnt sich außerdem unser Beitrag React und JavaScript Interviewfragen.

Wie teilen Sie Werkzeugeinstellungen über die Versionskontrolle?

Der zuverlässigste Weg, Einstellungen von Eslint und Prettier im Team zu teilen, ist die Versionskontrolle selbst. Für die Grundlagen deckt unsere Git und GitHub Anleitung die wichtigsten Befehle ab. Bearbeiten zwei Entwickler dieselbe Datei und es entsteht auch dort ein Konflikt, zeigt unser Beitrag Git Merge Konflikt lösen die Lösung.

Planen Sie, zu einem Open Source Projekt beizutragen? Unsere Anleitung zum Open Source Beitrag erklärt, warum die meisten Projekte genau diese Werkzeugabstimmung zuerst voraussetzen.

Verdienen Umgebungsvariablen und API Kommunikation dieselbe Sorgfalt?

Ja, die Werkzeugabstimmung ist nicht der einzige Punkt, der früh im Projekt Sorgfalt verdient. Geheimnisse, die versehentlich in ein Repository gelangen, sind ein ebenso häufiges Problem. Wir behandeln das in Env Datei versehentlich in Git committed. Für schnellere Kommunikation zwischen Diensten lohnt sich außerdem unser Beitrag Was ist gRPC.

Beide Themen sparen, ähnlich wie ein Eslint und Prettier Konflikt, später echte Zeit. Das gilt immer dann, wenn Sie sie von Anfang an richtig einrichten, statt sie später unter Druck zu reparieren.

Beeinflusst die Formatierung die Geschwindigkeit von Seite oder App?

Nicht direkt, denn Eslint und Prettier laufen nur während der Entwicklung. Sie gehören nie zum fertigen Produktionscode. Allerdings fällt ein Leistungsproblem bei sauberem Code oft früher auf. Unser Beitrag JavaScript Ladezeit und Performance optimieren beschreibt genau die Art von Problem, die solche Qualitätswerkzeuge früher sichtbar macht.

Kurz gesagt steigern Format und Qualitätswerkzeuge die Leistung nicht direkt. Eine saubere, einheitliche Codebasis spart aber Zeit, sobald Sie sich tatsächlich der Optimierung widmen. Außerdem fällt es in einer sauberen Codebasis leichter, genau zu erkennen, wo eine langsame Funktion tatsächlich liegt, statt in einer unübersichtlichen Datei danach zu suchen.