Claude Code ESLint: Konfiguration, Regeln und Auto-Fix mit KI

ESLint ist eines jener Werkzeuge, die jedes JavaScript- oder TypeScript-Projekt braucht — und die trotzdem regelmäßig zu Reibung führen. Konfigurationsdateien, die niemand mehr versteht. Regeln, die zu laut oder zu leise sind. Hunderte Verstöße im Legacy-Code, die sich niemand anzuschauen traut. Claude Code löst diese Probleme nicht durch neue Magie, sondern durch Kontext: Es liest deine bestehende Konfiguration, versteht dein Projekt, und handelt gezielt.

Dieser Artikel zeigt, wie du ESLint mit Claude Code einrichtest, konfigurierst und dauerhaft wartungsfrei hältst — von der Installation bis zum CI-integrierten Pre-commit-Hook.

1. ESLint installieren und initialisieren

Der erste Schritt ist immer gleich — ESLint ins Projekt holen und eine Basiskonfiguration erzeugen. Claude Code kann das vollständig übernehmen:

claude "Installiere ESLint in diesem Projekt und erstelle eine passende Konfiguration
für TypeScript und React. Erkläre kurz, was du einrichtest."

Claude Code liest package.json, erkennt ob TypeScript und React bereits verwendet werden, und wählt die passenden Pakete. Für moderne Projekte (ESLint 9+) wird automatisch das neue Flat-Config-Format verwendet — eine einzelne eslint.config.js statt der älteren .eslintrc.js oder .eslintrc.json.

Legacy-Format: .eslintrc.js

Ältere Projekte und ESLint-Versionen unter 9 nutzen noch das klassische Format:

// .eslintrc.js
module.exports = {
  env: {
    browser: true,
    es2021: true,
    node: true,
  },
  extends: [
    'eslint:recommended',
    'plugin:@typescript-eslint/recommended',
    'plugin:react/recommended',
  ],
  parser: '@typescript-eslint/parser',
  parserOptions: {
    ecmaVersion: 'latest',
    sourceType: 'module',
  },
  plugins: ['@typescript-eslint', 'react'],
  rules: {},
};

Neues Format: eslint.config.js (Flat Config)

Ab ESLint 9 ist das Flat-Config-Format Standard. Es ist expliziter, besser testbar und kommt ohne Glob-Magie aus:

// eslint.config.js
import js from '@eslint/js';
import tseslint from 'typescript-eslint';
import reactPlugin from 'eslint-plugin-react';

export default tseslint.config(
  js.configs.recommended,
  ...tseslint.configs.recommended,
  {
    plugins: { react: reactPlugin },
    rules: {
      'react/react-in-jsx-scope': 'off',
    },
    settings: {
      react: { version: 'detect' },
    },
  },
);

2. Empfohlene Regelsets verstehen und konfigurieren

ESLint-Konfigurationen bestehen meistens aus drei Schichten: einem Basis-Regelset, sprachspezifischen Erweiterungen und projektspezifischen Anpassungen. Claude Code hilft, diese drei Schichten sinnvoll zu trennen — statt alles in einer unübersichtlichen Datei zu vermengen.

• eslint:recommended — das Basis-Set, das offensichtliche Fehler und tote Variablen findet
• @typescript-eslint/recommended — TypeScript-spezifische Regeln: any-Warnungen, unbenutzte Importe, Typkonsistenz
• eslint-plugin-react / react-hooks — React-Muster: Hooks-Reihenfolge, fehlende Abhängigkeiten in useEffect
• eslint-plugin-import — Importreihenfolge, zirkuläre Abhängigkeiten, fehlende Module

Wenn du Claude Code bittest, das Regelset für ein bestehendes Projekt zu prüfen, bekommst du keine generische Empfehlung — sondern eine Analyse auf Basis deines tatsächlichen Codes:

claude "Welche ESLint-Regeln fehlen uns, die in einem TypeScript-React-Projekt
sinnvoll wären? Schau dir unsere bisherige Konfiguration und unsere Codebase an."

Eigene Regeln schreiben

Manchmal reichen die Standardregeln nicht. Projektspezifische Konventionen — etwa dass bestimmte Imports verboten sind, oder dass alle API-Funktionen einen bestimmten Namensprefix tragen müssen — lassen sich als Custom Rules abbilden. Claude Code schreibt diese auf Anfrage:

claude "Schreib eine ESLint-Custom-Rule, die verhindert dass console.log in
Produktionscode verwendet wird, console.error aber erlaubt."

Das Ergebnis ist eine vollständige Rule-Datei inklusive Tests — fertig zur Integration in dein lokales Plugin.

3. Auto-Fix: wie Claude Code ESLint-Verstöße behebt

ESLint kennt zwei Kategorien von Regeln: solche, die nur melden, und solche, die automatisch reparierbar sind. Mit dem Flag --fix werden alle automatisch behebbaren Verstöße direkt in den Dateien korrigiert.

npx eslint src/ --fix

Claude Code führt diesen Schritt aus — aber es geht weiter. Wenn nach dem automatischen Fix noch manuelle Verstöße übrig bleiben, analysiert Claude Code jeden einzelnen und behebt ihn gezielt. Das ist der entscheidende Unterschied zum bloßen --fix-Flag: Claude Code versteht den Kontext des Verstoßes und wählt die semantisch korrekte Lösung, nicht nur die technisch kompilierende.

claude "Führe ESLint mit --fix aus und behebe danach alle verbleibenden
Verstöße manuell. Erkläre bei komplexen Fällen kurz, warum du so vorgehst."

4. Integration mit Prettier und lint-staged

ESLint und Prettier erfüllen unterschiedliche Aufgaben: ESLint findet logische Fehler und Stilprobleme, Prettier formatiert. Beide zusammen zu verwenden erfordert Konfiguration, damit sie sich nicht gegenseitig widersprechen.

claude "Richte ESLint und Prettier so ein, dass sie konfliktfrei zusammenarbeiten.
Wir verwenden TypeScript und React."

Claude Code installiert eslint-config-prettier (deaktiviert ESLint-Regeln, die Prettier übernimmt), richtet .prettierrc ein und stellt sicher dass die Regelreihenfolge in eslint.config.js korrekt ist — Prettier-Config immer als letztes in der extends-Liste.

lint-staged: nur geänderte Dateien prüfen

ESLint auf das gesamte Projekt bei jedem Commit laufen zu lassen dauert zu lange. lint-staged prüft nur die Dateien, die tatsächlich im Staging-Bereich liegen:

// package.json
{
  "lint-staged": {
    "*.{ts,tsx,js,jsx}": [
      "eslint --fix",
      "prettier --write"
    ]
  }
}

Claude Code richtet diese Konfiguration auf Anfrage ein und verknüpft sie mit husky, damit der Hook automatisch bei jedem Commit greift.

5. Pre-commit-Hooks und CI mit GitHub Actions

Ein ESLint-Check, der nur lokal läuft, ist kein Gate — er ist eine Empfehlung. Wer die Hook-Konfiguration überspringt, kommt durch. Wer CI nicht hat, schiebt Probleme auf. Beides zusammen schafft die Grundlage für verlässliche Codequalität.

Pre-commit-Hook mit husky

claude "Richte husky ein, sodass ESLint und Prettier vor jedem Commit
automatisch auf den geänderten Dateien laufen."

Claude Code initialisiert husky, erstellt den .husky/pre-commit-Hook und verknüpft ihn mit lint-staged. Das Ergebnis: Jeder Commit auf dem Rechner läuft durch ESLint, bevor er abgeschlossen wird.

GitHub Actions CI

Für Teams, die auf Branches arbeiten, ist der CI-Check entscheidend. Ein einfacher Workflow, den Claude Code einrichten kann:

# .github/workflows/lint.yml
name: Lint

on: [push, pull_request]

jobs:
  eslint:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: '20'
          cache: 'npm'
      - run: npm ci
      - run: npx eslint src/ --max-warnings 0

Das Flag --max-warnings 0 ist entscheidend: Es lässt den CI-Job fehlschlagen, sobald auch nur eine ESLint-Warnung vorliegt — nicht erst bei Fehlern. Das verhindert, dass Warnungen sich über Monate ansammeln bis sie niemand mehr liest.

6. Wie Claude Code beim Massenfix und der Config-Migration hilft

Die drei häufigsten Szenarien, in denen Claude Code beim ESLint-Thema den größten Hebel hat:

Hunderte Verstöße im Legacy-Code beheben. Nicht per --fix alles auf einmal, sondern mit einem Plan: Claude Code kategorisiert die Verstöße nach Regelkategorie, priorisiert nach Risiko und behebt Kategorie für Kategorie — mit Commits dazwischen, damit die Git-History lesbar bleibt.

Von .eslintrc auf Flat Config migrieren. ESLint 9 ändert das Konfigurationsformat grundlegend. Claude Code liest die bestehende Konfiguration, übersetzt sie ins neue Format, und prüft ob alle Regeln und Plugins im neuen System verfügbar sind — inklusive der Randgruppenprobleme, bei denen Plugins noch keine offizielle Flat-Config-Unterstützung haben.

Custom Rules für Projektkonventionen. Wenn sich ein Muster im Code wiederholt das ESLint nicht von Haus aus erkennt — ein bestimmter Import, ein Anti-Pattern, eine fehlende Fehlerbehandlung — schreibt Claude Code die Custom Rule inklusive der Unit-Tests dafür. Keine Recherche in der ESLint-Plugin-API, kein Raten beim AST-Format.

"Schreib eine ESLint-Regel die sicherstellt, dass alle Funktionen die mit 'handle' beginnen ein explizites try/catch enthalten oder async mit einem catch am Aufrufer."

Dieser Prompt erzeugt eine vollständige Custom Rule, die genau das prüft. Kein Boilerplate selbst schreiben, kein AST-Explorer manuell befragen.

7. Fazit: ESLint als dauerhafter Standard statt einmaliger Setup

ESLint ist kein Einmal-Setup-Werkzeug. Codebases wachsen, Regeln veralten, neue Packages bringen neue Linting-Möglichkeiten. Mit Claude Code bleibt ESLint kein administrativer Overhead — es wird zu einem Teil des normalen Workflows: automatisch, kontextbewusst, wartungsarm.

Was Claude Code hier leistet, ist nicht das Ersetzen von ESLint-Wissen. Es ist das Eliminieren der Reibung, die zwischen "ich weiß, was ich will" und "ich habe es richtig konfiguriert" liegt. Für Teams, die professionell mit JavaScript und TypeScript arbeiten, ist das ein echter Produktivitätshebel.

• Installation und Konfiguration → einmaliger Prompt, richtige Pakete, richtiges Format
• Massenfix und Migration → strukturiert, mit Plan, Git-History bleibt lesbar
• Custom Rules → auf Anfrage, inklusive Tests, ohne AST-Recherche
• CI und Hooks → vollständig eingerichtet, kein manelles Konfigurieren

Zwei verwandte Artikel, die auf diesem Thema aufbauen:

• Claude Code TypeScript — Typsicherheit, Generics und automatische Typerkennung mit KI
• Claude Code CI/CD — automatisierte Pipelines mit GitHub Actions und Claude Code