Zastąpienie ESLint i Prettier narzędziem Biome: szybkość kontra zasada Hooks, której nadal potrzebujesz

Posty marketingowe promują binarnik Rust, pojedynczą konfigurację oraz zyski 20–50 razy większe. Następnie zmierzono czas działania w laboratorium z czterema ścieżkami, a potem policzono te przypadki diagnostyki, których Biome nie obsługuje.

Jeden binarnik w porównaniu z zestawami pluginów – czas wykonywania skrócił się. Natomiast zakres obsługi jednej ważnej reguły nie uległ zmianie.

Zobacz package.json.

Policz zależności związane z lintingiem. Projekty, które nadal zawierają eslint, prettier, eslint-config-prettier, eslint-plugin-react-hooks oraz plugin do analizy kodu, płacą „cichy podatek” przy każdym pushu. Biome sprzedaje się jako jeden plik wykonywalny do formatowania, sprawdzania kodu i sortowania importów.

Dodano Biome obok istniejącego zestawu narzędzi ESLint w tym laboratorium. Obie ścieżki przetwarzania zostały zmierzone pod kątem czasu wykonywania. Następnie usunięto ESLint. Diagnoza, od której zależało działanie, nie miała bezpiecznego odpowiednika w Biome. Ścieżka przetwarzania wykazała się pozytywnym wynikiem, a klasa błędu, która wcześniej blokowała pracę, pojawiła się ponownie na gałęzi funkcjonalnej.

Gałąź ponownie łączyła się z websocketem po zmianie tematu – to klasyczny przypadek zależności od efektów wizualnych. Biome pozostało ciche.

Zdanie, które faktycznie publikuje Biome

Oficjalnie Biome formatuje kod z dokładnością około 97% zgodnie z standardami Prettier oraz sprawdza go za pomocą obszernego zestawu reguł inspirowanych ESLint i typescript-eslint. Ustawienia znajdują się w pliku biome.json. Codzienne uruchamianie wygląda tak: pnpm exec biome check --write.

To, czego nie wspominają efektowne posty: mogą nadal brakować mniej znanych pluginów oraz własnych zasad. Można albo zachować ESLint do obsługi tych braków, albo przenieść odpowiednią logikę.

Szybkość jest łatwa do pokochania. Brak pokrycia to czynsz.

Rzeczywiste czasy zapisane

Laboratorium połączyło TypeScript, React oraz kilka modułów serwerowych — łącznie około sześćdziesięciu plików innych niż node_modules. Funkcja Instant Navigations została wyłączona, więc mierzono tylko narzędzie sprawdzające.

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

Każde z narzędzi uruchomiono trzy razy; wartości średnie:

• Tylko ESLint: 4,1s
• Prettier z opcją --check: 1,6s
• Najpierw ESLint, potem Prettier: 5,7s
• Biome z opcją check: 0,22s

Daleko nie 50 razy szybciej. W porównaniu z parą narzędzi działającymi sekwencyjnie jest to około 26 razy szybciej na małym drzewie strukturalnym. W artykułach blogowych często podaje się około 10 tysięcy plików. Ten zegar wykorzystywał aplikację, która faktycznie jest wdrażana. Trend jest zgodny; efektowny współczynnik mnożnikowy — nie.

Czyste sprawdzenie w porównaniu z Prettierem dało różnicę w dwóch plikach — długi otocznik właściwości JSX wewnątrz InvoiceRow. Otocznik użyty przez Biome został zachowany. Liczba 97% jest dokładna; pozostałe 3% stają się problematyczne tylko wtedy, gdy zespół analizuje pliki pojedynczo.

Jak to zobaczyć na swoim komputerze

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

Pojawi się plik biome.json. Uruchom Biome raz, dopóki ESLint jeszcze istnieje. Nie usuwaj niczego, dopóki nie będzie pisemnego spisu błędów ESLint, których Biome nigdy nie zgłasza.

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

Porównanie ręczne pokazało, że większość elementów z kategorii recommended się pokrywa. Bólący brak:

react-hooks/exhaustive-deps

Biome obejmuje sprawdzenia związane z hookami. Nie pokrywały one dokładnie tych samych ostrzeżeń, które wcześniej dotyczyły efektu socket. Po usunięciu tej zasady w CI przeciekła błądowa korekta tematu.

ESLint zgłosił problem tylko w jednym pluginie:

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

Niezdarny. Przezroczysty. Uruchamianie dwóch narzędzi to rozsądny, nowoczesny kompromis, gdy brakująca zasada ma nazwę. Przechowywanie pełnego drzewa ESLint „na wszelki wypadek” zazwyczaj jest marnotrawstwem.

Zwaliduj historię edytora tego samego wieczoru. Serwer językowy Biome zastąpił parę rozszerzeń. Nagle ostrzeżenia typu hooks pojawiły się tylko w środowisku CI — jeszcze gorzej lokalnie, chyba że rozszerzenie ESLint pozostanie dla tej konkretnej zasady. Lepiej widzieć je w /settings niż odkrywać podczas budowania rano.

Co jest tak naprawdę szybsze

Biome przegląda drzewo jako jeden proces natywny. ESLint to Node wraz z pluginami, często połączony z Prettierem. Przy sześćdziesięciu plikach ładowanie pluginów pochłania dużą część 4,1 sekundy. Przy tysiącach plików dominuje sam przegląd drzewa i pojawiają się wskaźniki na poziomie dużych projektów.

Biome 2 oferuje pewne funkcje sprawdzania poprawności kodu z uwzględnieniem typów, ale nie obejmuje pełnego zakresu funkcji typscript-eslint. Jeśli integracja ciągła nadal umożliwia użycie parserOptions.project, należy ocenić ten proces osobno – to właśnie jest kosztowny tryb ESLint. Można oczekiwać braków w porównaniu z starszymi opcjami no-unsafe-*.

Rachunek w szczegółach

Czas przetwarzania: z 5,7 sekundy do 0,22 sekundy. Monorepo odczuwają ten sukces najbardziej. Małe aplikacje przede wszystkim zyskują szybszą pracę na laptopie.

Zasady: zniknęła jedna kontrola zależności; ESLint pozostał dla tej ścieżki.

Konflikty dotyczące formatowania: dwa otoczenia JSX; da się to naprawić.

Edytor: dwie rozszerzenia połączyły się w jedno, a potem jedno z nich zostało usunięte – sytuacja w przybliżeniu równoważna, z szybszą kontrolą przez CLI.

Uwaga: zielony proces Biome to nie zielone drzewo hooków. W prośbach o integrację należy wskazać, który użytkownik oznaczył plik.

Zostaw to włączone albo zatrzymaj nocną zmianę

Repozytoria typu Greenfield mogą od dziś używać Biome do formatowania oraz weryfikacji podstawowej struktury kodu, całkowicie pomijając Prettier.

Drzewa typu Legacy powinny być sprawdzane dwukrotnie przez około tydzień. Zachowaj ESLint tylko dla nazwanych pluginów. Usuń niepotrzebne konfiguracje, a nie tylko krok CI.

Pozostanij przy ESLint, gdy to właśnie własne reguły stanowią produkt — i zapisz te reguły. „Może potrzebujemy pluginów” to nie jest inwentarz.

Nigdy nie usuwaj exhaustive-deps tylko dlatego, że Biome działa szybko. Zmiana tematu pokaże, dlaczego ta reguła istnieje.

Zastrzeżenia, które warto jasno sformułować

0,22 sekundy w porównaniu z 5,7 sekundami odnosi się do sześćdziesięciu plików na jednym laptopie — nie do korpusu 10 tysięcy plików, ani do twierdzenia o 56-krotnym przyspieszeniu.

Rozmiar luki między hakami zależy od ustawień konfiguracji oraz od wersji Biome z danej nocy. Uruchom ponownie biome rage i sprawdź aktualne informacje diagnostyczne dotyczące haków, zanim uznasz tę lukę za trwałą – identyfikatory zmieniają się w różnych wersjach.

Inwentarze pluginów są różne. Jeśli jedynym problemem jest kolejność importowania za pomocą eslint-plugin-import, spróbuj użyć funkcji organize-imports w Biome przez tydzień.

Zastosuj oba narzędzia. Wylistuj wszystkie usterki ESLint, które pozostają po wyczyszczeniu przez Biome.

To właśnie ta lista stanowi pracę migracyjną. Narzędzia te współpracują w ramach skryptu dual-lint z jasno określoną strukturą odpowiedzialności.

Gdy CI stało się zielone, a po ponownym połączeniu powrócił socket

ESLint w połączeniu z Prettier zostało zastąpione przez Biome. Czas sprawdzenia sześćdziesięciu plików: 0,22 sekundy w porównaniu z 5,7 sekund. Połączono gałąź. Zmiana tematu ponownie nawiązała połączenie przez websocket. Wcześniej react-hooks/exhaustive-deps blokowało ten schemat; Biome nie generowało już takich problemów.

Zła odpowiedź. Zatrzymaj socket do momentu zakończenia „migracji”. Klienci tracą aktualne dane.

Lepsza odpowiedź. Biome kontroluje format i podstawowe reguły sprawdzania kodu. ESLint pozostaje tylko dla jednego pluginu w folderze app.

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

Dwa rozwiązania są korzystne, gdy brakuje określonej reguły. Dwa rozwiązania są marnotrawne, gdy cała konfiguracja ESLint pozostaje bez zmian. Różnice w formacie: dwa otoczenia JSX; zachowana zostaje wersja Biome.

Pomierz na swoim własnym projekcie. Zapisz reguły dostępne tylko w ESLint po oczyszczeniu projektu przez Biome. Najpierw zapisz reguły, potem użyj stopera.

Polecenia i wyniki sesji laboratoryjnej

Wersje przed rozpoczęciem pracy: Node 24, TypeScript 7, Next 16.3. Zapisz je w notatce laboratoryjnej, aby kolejna sesja nie polegała na domysłach.

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

Umieść te trzy linijki na górze notatki. Jeśli istnieje poważna niezgodność z obowiązującym przewodnikiem, przerwij pracę — późniejsze polecenia mogą w sposób niezauważalny wprowadzić w błąd.

Kolejny krok w śledzeniu trasy:

pnpm exec next dev

Naciśnij /, /invoices, /invoices/1, /settings, a następnie ponownie /invoices. Pozostaw DevTools z włączoną funkcją zachowywania logów. Zapisz interfejs filtrów oraz adres URL – ta para jest przydatna w powiązanych eksperymentach.

Kontrola typów:

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

Kod wyjścia zero nie oznacza gotowego produktu. Służy jedynie do przygotowania ścieżki do sprawdzeń w czasie wykonywania.

Następnie uruchom ponownie polecenia z sekcji „Jak to zobaczyć na swoim komputerze”. Nie pomijaj ich tylko dlatego, że powyżej widnieją liczby. Inny komputer, temperatura otoczenia lub zajęte karty w Chrome wpłyną na ilość pamięci, czas trwania sprawdzeń oraz dokładność pomiarów bardziej niż aktualizacja frameworka.

Zapisz jednozdaniową notatkę o nieudanej próbie naprawy: „Próbowałem X, nadal widzę Y”. Wersje, polecenia, wyniki oraz to zdanie stanowią przydatne materiały pomocnicze. Zrzuty ekranu z marketingu nie są tak użyteczne.

Dziennik niepowodzeń

Usunięcie ESLinta w tym samym dniu, gdy pojawił się Biome, ponownie spowodowało problem z soketem. Przywrócenie jednego pluginu przywróciło pełną obsługę.

Próba naśladowania zachowania typscript-eslint dostosowanego do projektu w Biome 2 przyniosła częściowe pokrycie. Starszy zestaw reguł no-unsafe-* nie pasował. Udawanie inaczej przestało działać.

Długotrwały konflikt dotyczący formatowania właściwości JSX zakończył się przyjęciem Biome.

W edytorze rozszerzenia LSP Biome wyparły rozszerzenia Prettier i ESLint. Ostrzeżenia dotyczące hooks pojawiały się już tylko w środowisku CI, więc rozszerzenie ESLint pozostało w tym przypadku. Dwa rozszerzenia nadal są lepsze od pięciu.

Listwa kontrolna przed usunięciem ESLinta

• [ ] biome check kończy się pomyślnie
• [ ] Zapisano wszystkie reguły dotyczące wyłącznie ESLinta
• [ ] Nazwane pluginy są zachowywane lub świadomie porzucane
• [ ] exhaustive-deps ma zaufany odpowiednik, albo ESLint pozostaje w tym przypadku

[ ] Formaty delta są sprawdzane spokojnie, a nie przywracane w panice

[ ] Obie zegarki stoperowe zostały umieszczone na tym samym drzewie

0,22 s w porównaniu z 5,7 s to sześćdziesiąt plików. Zmierz ponownie lokalnie. Sprawdź ponownie diagnozy hakenów w zainstalowanym Biome, zanim uznasz tę różnicę za trwałą.

Uwaga produkcyjna z aplikacji faktur

CI oszczędza sekundy mierzone zegarem ściennym. Podczas demonstracji zmiana tematu przywróciła ponowne połączenie przez websocket, ponieważ pokrycie hakenów zniknęło. Sekundy nie są celem końcowym — celem jest łączna wartość w czasie rzeczywistym.

Lepiej wybrać wolniejszy lint, który wykrywa ponowne połączenia, niż szybki check, który je pomija. Połączenie Biome z czasem 0,22 s z jednym pluginem ESLint to również korzystna opcja. Nowe repozytoria mogą rozpocząć pracę wyłącznie z Biome i dodać ESLint, gdy tylko zostanie nazwana pierwsza reguła. Starsze repozytoria nie zyskają nic na teatralnych działaniach dotyczących czystości kodu.

Polecenia

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

Uruchom trzy razy; weź wartości średnie. Zapisz wyniki ESLint, Prettier oraz Biome. Wyeksportuj wyniki ESLint w formacie Unix i prześlij mapę błędów, których Biome nie wykryło. Umieść tę mapę w pull request; traktuj informacje o czasie jako przypis.

Znaczącą różnicą jest reguła, która nie ma odpowiednika.

Ćwiczenie dla czytelnika na rzeczywistym projekcie

Wybierz repozytorium, które jest gotowe do użycia, a nie środowisko testowe. Zapisz czasy wykonywania poleceń eslint ., prettier --check . oraz biome check . — po trzy takie uruchomienia każdego z nich. Utwórz tabelę z wartościami średnimi obok liczby plików.

Ręcznie sprawdź różnice w regułach przez chwilę; automatyczne przemiany nazw często wprowadzają w błąd. Wymień wszystkie błędy ESLint, które pozostają po oczyszczeniu projektu przez Biome. Pusta lista oznacza, że ESLint może zostać. Lista zawierająca react-hooks/exhaustive-deps lub krytyczny dla produktu plugin niestandardowy → zachowaj tę część.

Otwórz gałąź z hookiem, w którym brakująca zależność jest potwierdzona jako rzeczywista. Sprawdź, który narzędzie wyświetla komunikat błędu. To właśnie ta gałąź sprawia, że porównanie to nie jest zwykłym wyścigiem.

Zapisz tabelę oraz listę reguł. Unikaj prośby o pull request typu „switched to Biome”, która polega jedynie na usuwaniu pakietów. Usuwanie to ostatni krok, a nie pierwszy ruch.