ESLint

Was ist ESLint?

ESLint ist ein pluggable Linter für JavaScript und TypeScript. Es analysiert Ihren Code und überführt ihn in einen Syntax-Baum, wendet eine Reihe von Regeln darauf an und meldet Probleme. Die Regeln reichen von der Erkennung echter Bugs – ungenutzte Variablen, fehlende await, unsichere Gleichheitsprüfungen – bis hin zu Konventionen, die Ihr Team durchsetzen möchte.

Der Nutzen summiert sich. Jede Regel fängt eine bestimmte Fehlerklasse einmal, überall und für immer ab, anstatt sich darauf zu verlassen, dass Reviewer dies bemerken. Viele Regeln beheben Fehler zudem selbstständig, sodass eslint --fix eine überraschend große Menge an Code automatisch bereinigt. ESLint ist eines der effektivsten Tools in einem JavaScript-Projekt.

Flat Config

ESLint verwendet die flat config: eine Datei, die ein Array von Konfigurationsobjekten exportiert. Diese ersetzt das ältere .eslintrc-Format durch explizite Imports und eine vorhersehbare Zusammensetzung.

// eslint.config.js
import js from "@eslint/js";
import tseslint from "typescript-eslint";

export default tseslint.config(
  { ignores: ["dist", "coverage", "**/*.generated.*"] },
  js.configs.recommended,
  ...tseslint.configs.recommended,
  {
    files: ["**/*.ts", "**/*.tsx"],
    rules: {
      "@typescript-eslint/no-floating-promises": "error",
    },
  },
);

Jedes Objekt kann festlegen, für welche Dateien es gilt, welche Plugins es registriert und welche Regeln es definiert. Spätere Objekte überschreiben frühere, sodass das Array von oben nach unten wie eine Kaskade gelesen wird.

Regeln und Schweregrad

Jede Regel hat einen Schweregrad: "off", "warn" oder "error".

// rules.js
export default [
  {
    rules: {
      eqeqeq: "error",              // require ===
      "no-unused-vars": "warn",
      "no-console": ["warn", { allow: ["warn", "error"] }],
    },
  },
];

Einige Regeln akzeptieren Optionen, wie es no-console hier tut. error führt zum Fehlschlagen der CI; warn meldet den Fehler, ohne den Prozess zu stoppen. Verwenden Sie warn für Regeln, die Sie schrittweise einführen, und error für alles, was einen Merge blockieren sollte.

Plugins und Presets

Plugins fügen Regeln für spezifische Ökosysteme hinzu, während Presets eine kuratierte Auswahl dieser Regeln bündeln.

// react.js
import react from "eslint-plugin-react";
import reactHooks from "eslint-plugin-react-hooks";

export default [
  react.configs.flat.recommended,
  reactHooks.configs["recommended-latest"],
];

Gängige Plugins decken React, Vue, TypeScript, Imports, Testing-Libraries und Accessibility ab. Wenn man mit eslint:recommended startet und ein Framework-Preset hinzufügt, erhält man bereits 90 % des Nutzens bei fast keiner Konfiguration. Füge einzelne Regeln nur dann hinzu, wenn es einen konkreten Grund dafür gibt.

Typ-bewusstes Linting

typescript-eslint kann den TypeScript Type Checker für Regeln nutzen, die eine reine Syntax-Analyse nicht bewältigen kann.

// type-aware.js
export default tseslint.config({
  languageOptions: {
    parserOptions: {
      projectService: true,
      tsconfigRootDir: import.meta.dirname,
    },
  },
  rules: {
    "@typescript-eslint/no-floating-promises": "error",
    "@typescript-eslint/no-misused-promises": "error",
  },
});

Regeln wie no-floating-promises finden Bugs, die beim bloßen Lesen des Codes extrem schwer zu entdecken sind: zum Beispiel ein Promise, das niemals mit await aufgerufen wird. Typ-bewusstes Linting ist langsamer, da der Type Checker ausgeführt werden muss. Daher aktivieren viele Projekte diese Funktion für den Quellcode, lassen sie aber für Tests und Konfigurationsdateien weg.

Beheben und Deaktivieren

Viele Regeln lassen sich automatisch beheben. Führen Sie daher den Fixer aus, bevor Sie die Ausgabe lesen.

npx eslint . --fix

Wenn Sie eine Regel wirklich durchbrechen müssen, deaktivieren Sie diese so spezifisch wie möglich und begründen Sie dies.

// targeted.js
// eslint-disable-next-line no-console -- intentional debug log
console.log("payment flow", payload);

Ein pauschales /* eslint-disable */ am Anfang einer Datei schaltet alles aus – auch die Regeln, die echte Bugs erkannt hätten. Bevorzugen Sie eine einzeilige Deaktivierung mit einer Begründung und passen Sie die Konfiguration an, falls eine Regel mit Ihren Standards kollidiert.

Editoren und CI

Installiere die ESLint-Extension für deinen Editor und aktiviere „fix-on-save“. So erhältst du bereits während des Tippens Feedback und sichere Fixes werden sofort angewendet, wodurch das Linting Teil des Editing-Loops wird und nicht als lästige Pflicht empfunden wird. Führe ESLint in der CI als separaten Schritt aus, damit Fehler klar und schnell ersichtlich sind, und cache die Ergebnisse, sofern möglich.

Wo ESLint ins Spiel kommt

ESLint kümmert sich um die Code-Qualität; Prettier übernimmt die Formatierung. Das Standard-Setup sieht vor, dass Prettier für den Style zuständig ist, während die kollidierenden ESLint-Regeln deaktiviert werden – oft mithilfe einer Shared Config. Zusammen sorgen sie dafür, dass Reviewer über das Design diskutieren anstatt über Abstände und Semikolons.

Best Practices

• Beginnen Sie mit eslint:recommended und einem Framework-Preset und fügen Sie dann gezielt Regeln hinzu.
• Verwenden Sie die Flat Config mit expliziten Imports und einer klaren Ignores-Liste.
• Überlassen Sie das Formatting vollständig Prettier und deaktivieren Sie kollidierende ESLint-Regeln.
• Führen Sie --fix aus, bevor Sie die verbleibenden Probleme analysieren.
• Aktivieren Sie type-aware rules für Quelldateien.
• Deaktivieren Sie Regeln nur punktuell und fügen Sie einen Kommentar hinzu, der erklärt, warum.
• Nutzen Sie Linting im Editor, in einem Pre-Commit-Hook und in der CI.

Häufige Fehler

• Linting von dist, generiertem Code und Dependencies.
• Pauschales Deaktivieren von Regeln, anstatt die eigentliche Ursache zu beheben.
• Alle Regeln gleichzeitig aktivieren und im “Noise” versinken.
• Duplizieren von Formatierungsregeln, die bereits von Prettier übernommen werden.
• Type-aware Linting auf dem gesamten Repo ausführen und so die Performance verschlechtern.
• Warnings als harmlos betrachten, bis sie sich zu einem riesigen Berg aufstauen.

Wie geht es weiter?

ESLint ist das Quality Gate für deine Codebase. Kombiniere es mit Prettier für das Formatting, vertiefe die Typisierung mit TypeScript und binde es in den Vite Build sowie deine CI-Pipeline ein. Aktiviere anschließend eine neue Regel und behebe jeden entsprechenden Fehler – es ist eine kleine Gewohnheit mit einer großen Wirkung.