Startseite / Artikel / Biome statt ESLint und Prettier: Geschwindigkeit versus die Hooks-Regel, die Sie immer noch benötigen

Biome statt ESLint und Prettier: Geschwindigkeit versus die Hooks-Regel, die Sie immer noch benötigen

Zeitmessungen für Biome im Vergleich zu ESLint und Prettier, die Lücke bei react-hooks/exhaustive-deps sowie wann ein doppeltes Ausführen eines ESLint-Plugins die ehrliche Migrationsstrategie darstellt.

1944 Wörter

Marketing-Beiträge bewerben ein Rust-Binärdatei, eine einzige Konfiguration sowie Gewinne von 20–50-fach. Anschließend wurde ein Labor mit vier Routen getestet, wobei auch die Diagnosen berücksichtigt wurden, die Biome nicht unterstützt.

Eine Binärdatei im Vergleich zu Stapeln von Plugins – die Ausführungsdauer verringerte sich. Die Abdeckung für eine wichtige Regel tat dies jedoch nicht.

Prüfen Sie package.json.

Zählen Sie die mit Linting verbundenen Abhängigkeiten. Projekte, die weiterhin eslint, prettier, eslint-config-prettier, eslint-plugin-react-hooks sowie ein Parser-Plugin enthalten, zahlen bei jedem Push eine stillschweigende Gebühr. Biome bewirbt sich als ein einziges Ausführbarem Programm für Formatierung, Linting und Sortierung von Importen.

In jenem Labor wurde Biome neben der vorhandenen ESLint-Toolkette hinzugefügt. Beide Pipelines wurden zeitlich gemessen. Anschließend wurde ESLint entfernt. Eine abhängige Diagnose hatte keinen sicheren Biome-Äquivalent. Der Pipeline-Status wurde grün, und die Fehlerklasse, mit der diese Diagnose zuvor blockierte, tauchte auf einer Feature-Branch wieder auf.

Die Branch fügte bei einem Themawechsel erneut einen WebSocket hinzu – ein klassisches Problem durch Abhängigkeiten von Effekten. Biome blieb still.

Der Satz, den Biome tatsächlich ausgibt

Offiziell weist Biome eine Übereinstimmung mit Prettier von etwa 97 % auf und prüft den Code mit einer umfangreichen Regelmenge, die von ESLint und typescript-eslint inspiriert ist. Die Einstellungen befinden sich in biome.json. Die tägliche Nutzung sieht so aus wie pnpm exec biome check --write.

Was in den auffälligen Beiträgen weggelassen wird: Unbekannte Plugins und interne Regeln können weiterhin fehlen. Entweder behält man für diese Lücken ESLint oder portiert die Logik um.

Schnelligkeit ist leicht zu lieben. Mangelnde Abdeckung hingegen ist wie Miete.

Tatsächlich aufgezeichnete Zeiten

Das Labor kombinierte TypeScript, React sowie einige Server-Module – insgesamt etwa sechzig Dateien außerhalb von node_modules. Instant Navigations blieb deaktiviert, sodass nur der Checker gemessen wurde.

pnpm exec eslint . --max-warnings=0
pnpm exec prettier --check .
pnpm exec biome check .

Drei Durchläufe jeweils; Mittelwerte:

  • Nur ESLint: 4,1 s
  • Prettier --check: 1,6 s
  • Zuerst ESLint dann Prettier: 5,7 s
  • Biome check: 0,22 s

Weit entfernt von 50×. Im Vergleich zum sequenziellen Paar beträgt der Faktor bei einem kleinen Projekt etwa 26×. In Blog-Beispielen werden oft rund 10.000 Dateien angegeben. Diese Messung nutzte die tatsächlich eingesetzte Anwendung. Die Entwicklungstrends stimmen überein; der übertriebene Multiplikator hingegen nicht.

Bei der neuen Überprüfung kam es zwischen Prettier und dem Tool zu Uneinigkeiten bezüglich zweier Dateien – nämlich einer langen JSX-Prop-Umhüllung innerhalb von InvoiceRow. Biomes Umhüllung wurde beibehalten. Die 97%-Zahl ist ehrlich; die verbleibenden 3% werden erst zu einem Problem, wenn ein Team Datei für Datei diskutiert.

Wie man es auf dem eigenen Rechner sieht

pnpm add -D --save-exact @biomejs/biome
pnpm exec biome init

Es erscheint eine biome.json-Datei. Führen Sie Biome einmal aus, solange ESLint noch vorhanden ist. Entfernen Sie nichts, bevor es eine schriftliche Aufstellung der von ESLint erkannten Probleme gibt, die Biome nicht meldet.

pnpm exec eslint . -f unix > /tmp/eslint.txt
pnpm exec biome check --reporter=json > /tmp/biome.json

Durch manuelle Vergleiche zeigte sich, dass der größte Teil der in recommended aufgeführten Punkte übereinstimmte. Der problematische Unterschied bestand darin:

react-hooks/exhaustive-deps

Biome beinhaltet prüfungen, die mit Hooks zusammenhängen. Diese stimmten nicht mit der genauen Warnung überein, die zuvor im Zusammenhang mit einem Socket-Effekt konfiguriert worden war. Nachdem die CI-Systeme diese Regel entfernt hatten, entging eine Fehlermeldung bezüglich des Themenwechsels.

ESLint meldete sich nur für ein einzelnes Plugin:

{
  "scripts": {
    "lint": "biome check . && eslint app --plugin react-hooks --rule 'react-hooks/exhaustive-deps:error'"
  }
}

Unhandlich. Transparent. Das gleichzeitige Verwenden von zwei Tools ist ein angemessener moderner Kompromiss, wenn die fehlende Regel einen Namen hat. Ein vollständiges ESLint-Tree „für alle Fälle“ zu behalten, ist in der Regel Verschwendung.

Überprüfen Sie die Editor-Änderungen noch am selben Abend. Biomes Sprachserver ersetzte ein Paar Erweiterungen – plötzlich tauchten die Hook-Warnungen nur noch im CI auf; lokal war die Situation schlimmer, es sei denn, die ESLint-Erweiterung blieb für diese eine Regel aktiv. Es ist besser, die Warnungen in /settings zu sehen, anstatt sie erst beim morgendlichen Build entdecken zu müssen.

Was ist tatsächlich schneller

Biome durchläuft das Tree als ein einziger natives Prozess. ESLint setzt sich aus Node und Plugins zusammen, oft ergänzt durch Prettier. Bei sechzig Dateien verbraucht das Laden der Plugins einen großen Teil der 4,1 Sekunden. Bei Tausenden von Dateien dominiert das Durchlaufen des Trees, und dann treten marktübliche Leistungsverhältnisse auf.

Biome 2 bietet eine artbezogene Linting-Funktion, ist aber nicht die vollständige Funktionalität von typescript-eslint. Wenn die kontinuierliche Integration weiterhin parserOptions.project ermöglicht, sollte dieser Vorgang getrennt bewertet werden – schließlich handelt es sich dabei um den ressourcenintensiven ESLint-Modus. Im Vergleich zu den älteren no-unsafe-*-Einstellungen sind daher Lücken zu erwarten.

Dass die projektbezogene Parsing-Funktion deaktiviert wurde, die Laufzeit in der CI von etwa 90 Sekunden auf etwa 8 Sekunden sank und Biome dafür verantwortlich gemacht wird, ist irreführend – schließlich wurde lediglich der artbezogene Prüfflauf entfernt. Sagen Sie das laut, wenn das passiert.

Die Aufschlüsselung

Pipeline-Zeit: von 5,7 Sekunden auf 0,22 Sekunden hier. Monorepos spüren den Vorteil am stärksten. Kleine Anwendungen profitieren hauptsächlich von einer schnelleren Ausführung auf dem Laptop.

Regeln: Eine abhängige Überprüfung verschwand; ESLint bleibt für diesen Pfad bestehen.

Formatierungsprobleme: Zwei JSX-Umhüllungen; lösbar.

Editor: Zwei Erweiterungen wurden zu einer, anschließend kehrte eine zurück – im Großen und Ganzen ausgeglichen, mit einer schnelleren CLI-Überprüfung.

Achtung: Ein grüner Biome-Run ist nicht gleichbedeutend mit einem grünen Hooks-Baum. In Pull Requests sollte angegeben werden, welcher Ausführende die Datei markiert hat.

Lassen Sie es aktiv, oder beenden Sie den Nachtschicht-Modus

Greenfield-Repos können Biome noch heute Abend für Formatierung sowie grundlegende Lint-Prüfungen einsetzen und Prettier ganz weglassen.

Legacy-Bäume sollten etwa eine Woche lang doppelt ausgeführt werden. Behalten Sie ESLint nur für benannte Plugins bei. Löschen Sie ungenutzte Konfigurationen – nicht nur die CI-Schritte.

Bleiben Sie bei ESLint, wenn eigene Regeln das Produkt sind – und schreiben Sie diese Regeln auf. „Vielleicht brauchen wir Plugins“ ist keine Inventarliste.

Lassen Sie niemals exhaustive-deps weg, nur weil Biome schneller ist. Ein Theme-Wechsel wird zeigen, warum die Regel notwendig war.

Hinweise, die klar ausgesprochen werden sollten

0,22 Sekunden gegenüber 5,7 Sekunden beziehen sich auf sechzig Dateien auf einem Laptop – nicht auf ein Korpus mit 10.000 Dateien, auch keine Angabe von 56-fachem Vorteil.

Die Lücke der Hooks hängt von der Konfiguration sowie vom Build des jeweiligen Bioms ab. Führen Sie biome rage erneut aus und prüfen Sie die aktuellen Diagnosedaten der Hooks, bevor Sie das Loch als dauerhaft betrachten – die Identifikatoren ändern sich bei neuen Versionen.

Die Inventare der Plugins unterscheiden sich. Falls die Reihenfolge der Importe über eslint-plugin-import das einzige Problem darstellt, probieren Sie Biomes Funktion „organize-imports“ eine Woche lang aus.

Stellen Sie beide Tools auf die gleiche Zeit ein. Zählen Sie die ESLint-Fehler auf, die nach der Reinigung durch Biome noch vorhanden sind.

Diese Auflistung ist die Migrationsarbeit. Die Überlebenden versorgen ein doppeltes Lint-Skript mit klarem Verantwortungsbereich.

Als CI grün wurde und eine Wiederverbindung hergestellt werden konnte

ESLint plus Prettier wurden durch Biome ersetzt. Prüfzeit für sechzig Dateien: 0,22 Sekunden gegenüber 5,7 Sekunden. Eine Branch wurde verschmolzen. Das Ändern des Themes führte zur erneuten Verbindung eines WebSocket-Streams. react-hooks/exhaustive-deps blockierte zuvor dieses Muster; Biome erzeugte keinen entsprechenden Fehler mehr.

Schlechte Reaktion. Parken Sie den Socket, bis „die Migration abgeschlossen ist“. Die Kunden verlieren die Echtzeit-Anzeige.

Bessere Reaktion. Biome übernimmt das Format sowie die Grundregeln zur Fehlerprüfung. ESLint bleibt für ein Plugin unter app erhalten.

{
  "scripts": {
    "lint": "biome check . && eslint app --plugin react-hooks --rule 'react-hooks/exhaustive-deps:error'"
  }
}

Zwei Ansätze sind sinnvoll, wenn die fehlende Regel benannt wird. Zwei Ansätze sind verschwenderisch, wenn die gesamte ESLint-Konfiguration erhalten bleibt. Formatierungsunterschiede: zwei JSX-Umhüllungen; die Version von Biome wird beibehalten.

Messen Sie an Ihrem eigenen Projekt. Führen Sie nachdem Biome sauber ist, nur die ESLint-eigenen Regeln auf. Zuerst katalogisieren, anschließend mit Stoppuhr messen.

Befehle und Ausgaben der Lab-Sitzung

Versionen vor dem Start: Node 24, TypeScript 7, Next 16.3. Speichern Sie diese in einer Lab-Notiz, damit die nächste Sitzung nicht auf Vermutungen beruht.

node -v
pnpm exec tsc -v
pnpm exec next --version

Fügen Sie diese drei Zeilen an den Anfang der Notiz ein. Wenn es erhebliche Abweichungen vom befolgten Leitfaden gibt, stoppen Sie – spätere Befehle könnten sonst heimlich in die Irre führen.

Nächster Routenweg:

pnpm exec next dev

Gehen Sie zu /, /invoices, /invoices/1, /settings und anschließend wieder zu /invoices. Lassen Sie die Protokollierung in DevTools aktiv. Erfassen Sie die Filter-Oberfläche sowie die URL – dieses Paar ist bei verwandten Experimenten nützlich.

Typprüfung:

pnpm exec tsc --noEmit --pretty false
echo $?

Ein Abbruchcode null ist kein fertiges Produkt. Er führt lediglich zum Wegfall der Prüfungen während der Ausführung.

Führen Sie danach die Entdeckungskommandos aus dem Abschnitt „Wie man es auf dem eigenen Rechner sieht“ erneut aus. Überspringen Sie diese nicht nur wegen der oben angezeigten Zahlen. Ein anderer Rechner, Umgebungstemperatur oder viele aktive Chrome-Tabs können den Speicherverbrauch, die Prüfdauer sowie die Zeitmessung stärker beeinflussen als ein Framework-Update.

Führen Sie einen Eintrag mit einer einzigen Zeile für fehlgeschlagene Lösungsversuche ein: „Versucht habe ich X, es trat weiterhin Y auf.“ Versionen, Befehle, Ausgaben sowie dieser Satz bilden wertvolles Material für weitere Schritte. Marketing-Screenshots nicht.

Fehlerprotokoll

Das Entfernen von ESLint am selben Tag, an dem Biome eingeführt wurde, brachte das Socket-Problem wieder zurück. Das Wiederherstellen eines Plugins stellte die Abdeckung wieder her.

Der Versuch, das projektbezogene Verhalten von typescript-eslint in Biome 2 nachzuahmen, führte zu einem teilweisen Überschneiden. Die ältere no-unsafe-*-Gruppe passte nicht. Das Vortäuschen eines anderen Verhaltens brach ab.

Ein langer Konflikt bezüglich der Formatierung von JSX-Propen endete mit der Akzeptanz von Biome.

In der Editor-Software verdrängte Biomes LSP die Prettier- und ESLint-Erweiterungen. Warnungen wegen Hooks erschienen danach nur noch in CI, weshalb die ESLint-Erweiterung für diese Regel beibehalten wurde. Zwei Erweiterungen sind immer noch besser als fünf.

Checkliste vor dem Entfernen von ESLint

  • [ ] biome check läuft sauber ab
  • [ ] Nur die ESLint-regelbasierten Regeln werden aufgeschrieben
  • [ ] Benannte Plugins werden beibehalten oder bewusst aufgegeben
  • [ ] exhaustive-deps hat einen zuverlässigen Ersatz, oder ESLint bleibt für dieses Tool
  • [ ] Format-Deltas werden ruhig überprüft, nicht in Panik rückgängig gemacht
  • [ ] Beide Stoppuhren wurden am selben Baum aufgenommen
  • 0,22 Sekunden gegenüber 5,7 Sekunden – das sind sechzig Dateien. Messen Sie lokal erneut nach und überprüfen Sie die Diagnosen der Hooks im installierten Biome, bevor Sie den Unterschied als dauerhaft betrachten.

    Produktionshinweis aus der Rechnungs-App

    CI hat Wanduhrsekunden gespart. Während einer Demo führte das Wechseln des Themes zu einer erneuten Verbindung über WebSocket, da die Coverage der Hooks verschwunden war. Sekunden sind nicht das Ergebnis – das Live-Aggregat ist es.

    Ziehen Sie einen langsameren Linter vor, der Wiederverbindungen erkennt, anstatt einen schnellen Check, der sie übersehen könnte. Die Kombination von 0,22 Sekunden Biome mit einem ESLint-Plugin ist ebenfalls ein gutes Angebot. Neue Repositorien können direkt mit Biome beginnen und ESLint erst hinzufügen, sobald eine Regel benannt ist. Ältere Repositorien profitieren nicht vom „Purity Theatre“.

    Befehle

    pnpm exec eslint . --max-warnings=0
    pnpm exec prettier --check .
    pnpm exec biome check .
    

    Starten Sie dreimal; nehmen Sie die Medianwerte. Protokollieren Sie ESLint, Prettier sowie Biome. Speichern Sie die Ausgabe von ESLint im Unix-Format und kartieren Sie die von Biome nicht erkannten Fehler. Fügen Sie diese Karte der Pull-Request-Datei hinzu; betrachten Sie die Zeitangaben als Fußnote.

    Der bedeutende Unterschied liegt in den Regeln, die kein Gegenstück haben.

    Leseeinheit anhand eines echten Projekts

    Wählen Sie ein bereitgestelltes Repository, nicht eine Sandbox. Erfassen Sie die Ausführungszeiten für eslint ., prettier --check . und biome check . – jeweils drei Durchläufe. Tabellieren Sie die Medianwerte zusammen mit der Anzahl der Dateien.

    Bauen Sie den Regeldifferenzbericht vorübergehend manuell auf; automatische Umbenennungen führen oft zu Fehlinterpretationen. Listeten Sie alle ESLint-Fehler auf, die nach der Ausführung von Biome noch vorhanden sind. Leere Liste → ESLint-Ergebnisse können weggelassen werden. Liste mit react-hooks/exhaustive-deps oder einem für das Produkt kritischen benutzerdefinierten Plugin → dieser Teil muss beibehalten werden.

    Eröffnen Sie eine Branch mit einem Hook, dessen fehlende Abhängigkeit als vorhanden bekannt ist. Prüfen Sie, welches Tool sich beschwert. Wegen dieser Branch ist der Vergleich nicht einfach nur ein Wettlauf.

    Committen Sie die Tabelle sowie die Regelliste. Vermeiden Sie Pull Requests vom Typ „Auf Biome umgestellt“, die nur Pakete löschen. Die Löschung ist der abschließende Schritt, nicht die erste Handlung.