Wir haben beschlossen, nicht auf den perfekten Linter zu warten: ESLint-V9-Migration und die Einführung eines Biome-Hybrids

Als Reaktion auf das Support-Ende von ESLint V8 migrierte das Frontend-Chapter von Lemonbase auf V9 und löste Performance-Probleme durch die Einführung eines Biome-Hybridmodells. Hier teilen sie ihre Erfahrungen.

Hintergrund der Einführung

• Im September 2024 wurde das Support-Ende von ESLint V8 angekündigt; um weiterhin Security-Patches und Bugfixes zu erhalten, war die Migration auf V9 zwingend erforderlich
• Ab V9 sind .eslintrc.js-basierte Konfigurationen deprecated, und Flat Config wird zum Standard
• Rund 400 Regeln, eine zweigeteilte Struktur der Konfigurationsdateien und die Prüfung der Kompatibilität verschiedener Plugins mussten berücksichtigt werden

Migrationsprozess

• Das offizielle Migrationstool von ESLint blieb hinter den Erwartungen zurück, da es im Wesentlichen nur per @eslint/compat wrapped
• Mit AI-Tools wurde ein erster Entwurf erstellt, doch dabei traten zahlreiche fehlende Regeln und Kompatibilitätsprobleme auf
• Am Ende wurden die V8-/V9-Regeln Zeile für Zeile in einer Tabelle verglichen und vollständig überprüft

Performance-Probleme nach der Migration

• Nach dem Upgrade auf V9 wurde es sogar langsamer: von 154 Sekunden auf 184 Sekunden, also 30 Sekunden mehr
• Die Regel import/no-cycle war im Vergleich zu V8 zehnmal langsamer und machte 45,8 % der Gesamtzeit aus
• Die Regel prettier/prettier lag ebenfalls bei 10,2 %, wobei der Overhead durch doppeltes Parsing zum Flaschenhals wurde

Einführung eines Biome-Hybrids

• Statt einer vollständigen Ablösung wurde der Ansatz auf „gemeinsam nutzen und sich auf den Nutzen konzentrieren“ umgestellt
• Austausch von Prettier → Biome Formatter, wodurch sich die Formatierungszeit von 14 Sekunden auf 2 Sekunden verkürzte
• ESLint ist nur noch für projektspezifische Custom-Regeln zuständig

Endergebnis

• ESLint V8: 154 Sekunden → ESLint V9: 184 Sekunden
• Nur ESLint → Biome + ESLint Hybrid: ~20 Sekunden

Erkenntnisse

• Wenn man AI mit einer Migration beauftragt, sollte man sie zuerst einen Plan erstellen lassen, diesen von Menschen prüfen und Erfolgskriterien klar definieren, z. B. Übereinstimmung mit den V8-Ergebnissen
• Statt auf das perfekte Tool zu warten, ist es manchmal der schnellere Weg, die bereits verfügbaren Tools gut zu kombinieren

Wichtige Punkte

• Wenn zwei Tools gemeinsam genutzt werden, müssen sowohl eslint.config.mjs als auch biome.json gepflegt werden, und es besteht die Möglichkeit von Regelkonflikten
• Es sollte klar festgelegt werden, welches Tool für welche Regeln zuständig ist; außerdem muss die Rollenverteilung beim Onboarding neuer Teammitglieder erklärt werden

[selene]

Ich denke, das ist ein Artikel, der denen gute Einblicke geben kann, die immer noch mit Problemen bei der Lint-Performance zu kämpfen haben.

Auch wir haben im vergangenen Jahr unsere Nutzung von oxc (oxlint) und ESLint als Hybrid verbessert und dabei die Lint-Zeit von über 200 Sekunden auf unter 15 Sekunden reduziert.

Auch ich habe die Migration anfangs mit AI eher grob vorangetrieben, aber weil immer wieder Regeln fehlten oder verfälscht wurden, habe ich überlegt, sie einzeln zu prüfen.
Dann habe ich jedoch ein Skript, das die von oxc unterstützten Regeln extrahiert, mit AI erstellt und es so verbessert, dass nur die von oxc nicht unterstützten Regeln in ESLint aktiviert werden. Dadurch ist es jetzt auch deutlich einfacher geworden, neu unterstützte Regeln regelmäßig zu aktualisieren...

Anfangs war dieser Prozess halb automatisiert, aber inzwischen habe ich ihn als Skill definiert, sodass ich ihn einfach mit Claude Code ausführen kann. Das hat die Hürde deutlich gesenkt, was ich sehr angenehm fand.

[chamchi]

Wäre es nicht eine Überlegung wert, statt eslint und prettier einmal oxlint und oxfmt auszuprobieren?
Bei einer 1:1-Entsprechung der Konfiguration ist die Geschwindigkeit mindestens um ein Vielfaches höher, oft um mehrere Dutzend Male.