Czym jest ESLint?

ESLint to narzędzie kontroli jakości kodu JavaScript/TypeScript, które automatycznie wykrywa niespójności stylu, błędy logiczne, antywzorce oraz potencjalne problemy wydajnościowe i bezpieczeństwa. Służy do utrzymania spójnych standardów programistycznych w projektach front-end i back-end, porządkuje kod, upraszcza code review i zmniejsza liczbę błędów trafiających do produkcji. Jego siła pochodzi z rozszerzalnej architektury, precyzyjnych zasad (rules), bogatego ekosystemu wtyczek oraz ścisłej integracji z edytorami, systemami kontroli wersji i pipeline’ami automatyzacji. W ujęciu słownikowym jest to statyczny analizator kodu (linter) skoncentrowany na języku JavaScript oraz jego odmianach, zdolny nie tylko zgłaszać problemy, ale także je automatycznie naprawiać, kiedy jest to bezpieczne i zgodne z intencją autora.

Definicja, pochodzenie i miejsce w ekosystemie web

ESLint powstał jako odpowiedź na ograniczenia wcześniejszych linterów, które nie dawały wystarczającej kontroli nad zachowaniem reguł oraz nie były łatwe w rozbudowie. Zaprojektowano go w duchu modułowości i możliwości adaptacji do różnych stylów oraz standardów kodowania. Tym, co odróżnia go od poprzedników, jest obszerna biblioteka bazowych zasad oraz możliwość tworzenia własnych, dziedzinowych rozszerzeń. Dzięki temu może jednocześnie pełnić rolę narzędzia edukacyjnego, pokazując deweloperom lepsze wzorce, i operacyjnego, wymuszając minimalne standardy jakości przed kompilacją czy wdrożeniem.

W praktyce oznacza to, że w zespole można zdefiniować wspólny pakiet zasad, który będzie równy dla każdego członka, niezależnie od systemu operacyjnego, edytora czy poziomu doświadczenia. Znika potrzeba ręcznego tropienia odchyleń w code review – narzędzie robi to automatycznie i w sposób bezstronny. Poprawia to przepływ pracy, skraca czas przeglądów oraz pomaga nowym członkom zespołu wejść w projekt z mniejszą liczbą pytań o konwencje. Co ważne, ESLint nie ogranicza się do stylistyki – obejmuje liczne klasy błędów, od literówek w importach, przez użycie przestarzałych API, po niebezpieczne konstrukcje.

Na przestrzeni lat narzędzie stało się standardem de facto w projektach webowych. Wraz z pojawieniem się bibliotek i frameworków uczyniło możliwym dopasowanie kontroli jakości do specyfiki React, Vue, Angular czy Node.js. W tym ekosystemie ugruntowało pozycję jako pierwszy element łańcucha jakości: wczesne ostrzeżenia na etapie edycji kodu są tańsze w obsłudze niż błędy znalezione po podniesieniu środowiska, a tym bardziej po wdrożeniu na produkcję. Dzięki aktywnej społeczności i szerokim integracjom można traktować je jako warstwę infrastruktury jakościowej – stabilną, przewidywalną i poddającą się automatyzacji.

Jak działa ESLint pod maską

Serce narzędzia stanowi analiza składniowa, czyli przekształcenie źródeł w strukturę drzewa syntaktycznego. To umożliwia regułom rozpoznawanie wzorców w kodzie i raportowanie nieprawidłowości. Domyślnie wykorzystywany jest parser Espree, ale w zależności od języka i dialektu można zastąpić go innymi. Mechanizm odwiedzania węzłów (visitor pattern) pozwala regułom reagować na konkretne konstrukcje językowe – deklaracje, wywołania funkcji, instrukcje kontroli przepływu i wiele innych. W efekcie narzędzie ma pełny obraz kodu na poziomie strukturalnym, a nie tylko tekstowym, co zwiększa precyzję wykrywania problemów.

Reguły działają niezależnie, każda z nich ma własną semantykę i parametryzację. W większości przypadków można wskazać wagę problemu – ostrzeżenie lub błąd – oraz przekazać szczegółowe opcje konfiguracji. Prosty przykład to wymuszenie spójnych cudzysłowów, bardziej zaawansowany – wykrywanie nieużywanych zmiennych z uwzględnieniem wyjątków. Wiele reguł posiada wbudowane autofixy, które mogą poprawić kod bez ingerencji autora, zachowując ostrożność tam, gdzie potencjalna zmiana znaczenia byłaby ryzykowna. Dzięki temu uruchomienie narzędzia potrafi jednocześnie wskazać i naprawić znaczną część usterek.

Ważnym elementem jest też raportowanie. ESLint potrafi zwracać wyniki w różnych formatach – od czytelnego dla człowieka po strukturyzowane dane przydatne w systemach ciągłej integracji. Można wymusić przerwanie procesu budowania, jeśli wykryto błędy lub jeśli liczba ostrzeżeń przekracza określony próg. Dodatkowo dostępny jest cache, który skraca czas wielokrotnego uruchamiania na niezmienionych plikach. Przy dużych repozytoriach i złożonych konfiguracjach daje to realne oszczędności czasu oraz zasobów obliczeniowych.

Podczas interpretacji plików istnienie różnych środowisk jest rozróżniane przez ustawienia: przeglądarka, Node.js, testy. Pozwala to dostosować listę globali i specyficznych zachowań, by unikać fałszywych alarmów i wychwytywać błędy typowe dla danego kontekstu. Narzędzie potrafi również rozumieć różne moduły (ESM, CommonJS) i rozszerzenia plików, a także reguły dotyczące importów, aliasów i rozwiązywania ścieżek. W przypadku nietypowych dialektów składni, jak JSX czy dekoratory, odpowiednie ustawienia parsera i rozszerzenia konfiguracji zapewniają pełną kompatybilność.

Konfiguracja: pliki, styl i dziedziczenie

Jedną z największych zalet narzędzia jest elastyczna konfiguracja. Historycznie dominował format .eslintrc.* (JSON, YAML, JS), obecnie preferowany jest tzw. płaski model (flat config) z plikiem eslint.config.js lub eslint.config.mjs. Płaska konfiguracja ułatwia łączenie wielu zestawów zasad i pluginów, ogranicza niejednoznaczności rozwiązywania plików konfiguracyjnych i poprawia wydajność. Pozwala także definiować reguły i opcje w postaci tablicy bloków dopasowywanych do wzorców plików. Dzięki temu np. inny zestaw zasad można zastosować do testów, a inny do kodu produkcyjnego, bez komplikowania struktury projektu.

Konfiguracja obejmuje m.in. ustawienia parsera i jego opcji, listę środowisk, globalne zmienne, definicję reguł, aliasów importów, ignorowania plików oraz dziedziczenie profili. Dziedziczyć można zarówno oficjalne profile jak eslint:recommended, jak i profile społecznościowe (Airbnb, Standard, Google) czy firmowe „shareable configs”. Korzystanie z dziedziczenia ogranicza ryzyko powielania ustawień, a centralizacja logiki sprzyja spójności. Warto przy tym zwrócić uwagę na zasady priorytetu i kolejność nakładania – ostatni pasujący wpis ma pierwszeństwo, co pomaga w precyzyjnym dopasowaniu do struktury repozytorium.

Istnieje też mechanizm ignorowania, który pozwala pominąć katalogi generowane, artefakty buildów, bundlowane biblioteki i zasoby, których analiza nie ma sensu. Ignorowanie może być globalne (np. przez .eslintignore), w konfiguracji płaskiej (patterny w blokach), a także liniowe w kodzie poprzez komentarze dyrektyw. Użycie komentarzy powinno być oszczędne i z wyjaśnieniem – zbyt częste tłumienie ostrzeżeń wskazuje na problem w zestawie zasad lub procesie wytwórczym. Strukturalne ignorowanie (wzorce katalogów) zwykle jest bezpieczniejsze i bardziej zrozumiałe dla zespołu.

Warto też podkreślić, że zamiana starego modelu .eslintrc na nowy ułatwia standaryzację w monorepo, przy jednoczesnej kontroli nad kolejnością nakładania ustawień i zasięgiem. Z kolei w mniejszych repozytoriach płaski model redukuje liczbę plików w projekcie. Dobrą praktyką jest utrzymywanie komentarzy z kontekstem decyzji, opisu kompromisów oraz źródłami zaleceń, tak by kolejni opiekunowie projektu rozumieli stojące za nimi motywacje.

Reguły, profile i ekosystem wtyczek

Podstawowym budulcem są reguły – drobne polityki jakościowe koncentrujące się na wybranym aspekcie kodu. Katalog oficjalnych zawiera setki pozycji, a społeczność tworzy tysiące dodatkowych. Od prostych zasad stylistycznych (wcięcia, średniki), przez logiczne (brak nieużywanych zmiennych, spójność importów), po bezpieczeństwo (zakaz eval, walidacja użycia operatorów). Niektóre reguły są ogólne i działają w każdym projekcie, inne wymagają dopasowania do technologii. Przykładowo, katalog JSX i reguły dostępności są kluczowe w aplikacjach React, podczas gdy projekty Node korzystają z zasad dotyczących środowiska serwerowego.

Kolejnym filarem są pluginy. Zawierają one zestawy reguł i konfiguracje specyficzne dla danej biblioteki, frameworka albo domeny problemu. Popularne to m.in. eslint-plugin-react, eslint-plugin-react-hooks, eslint-plugin-jsx-a11y, eslint-plugin-import, eslint-plugin-unicorn, eslint-plugin-promise, eslint-plugin-security, eslint-plugin-jest, eslint-plugin-testing-library, @typescript-eslint/eslint-plugin, eslint-plugin-vue. Często w parze idą one z parserami i dodatkowymi resolverami modułów. Dzięki wtyczkom można rozszerzyć ESLint o specjalistyczną wiedzę: poprawne wzorce hooków w React, reguły dla testów, zaawansowane sprawdzanie importów, konwencje dla Vue i wiele innych. Ekosystem jest żywy i stale rosnący, co przekłada się na szybkość adaptacji do nowych bibliotek i wzorców w JavaScript.

Ważnym tematem jest rozdział odpowiedzialności między narzędzia do formatowania a narzędzie do analizy semantycznej. ESLint potrafi formatować fragmenty kodu, ale złożone formatowanie (układ linii, cudzysłowy, przecinki) skuteczniej realizuje dedykowany formater. Połączenie osiąga się na dwa sposoby: wyłączenie reguł kolidujących i pozostawienie formatowania formaterowi, albo uruchamianie go jako dodatkowej reguły. Najpopularniejsza praktyka to rozdzielić obowiązki – formater dba o layout, a ESLint o sens i poprawność. Taki porządek minimalizuje konflikty i zmniejsza liczbę sztucznych zmian w commitach.

Przykładowe profile startowe obejmują oficjalny zbiór rekomendowany, który zawiera równowagę między wykrywaniem realnych problemów a niską liczbą fałszywych alarmów. Profile społecznościowe, jak Airbnb, kładą nacisk na konkretne style i wzorce. Firmy często tworzą własne „shareable configs”, aby precyzyjnie odwzorować standardy danej organizacji. Wdrożenie tych profili ułatwia nowym zespołom adaptację i skraca czas ustawiania projektu. Jednocześnie warto pamiętać o regularnych aktualizacjach – świat JavaScript szybko się zmienia, a reguły muszą za tym nadążać.

Integracje z edytorami, pipeline’ami i zespołowym workflow

Jednym z kluczowych motorów adopcji jest integracja z edytorami. W Visual Studio Code wystarczy zainstalować rozszerzenie ESLint i włączyć automatyczne poprawki przy zapisie. To daje natychmiastową informację zwrotną, skraca pętlę „napisz-sprawdź” i pozwala łapać problemy, zanim kod trafi do repozytorium. W JetBrains IDE (WebStorm i inne) wsparcie jest natywne, a w Vim/Neovim można korzystać z LSP lub dedykowanych wtyczek. Konfiguracje można wersjonować w repozytorium, aby każdy członek zespołu miał identyczny zestaw ustawień, co eliminuje rozbieżności środowiskowe.

ESLint jest naturalną częścią automatyzacji. W pipeline’ach CI/CD uruchamia się go dla całego projektu lub tylko zmienionych plików, a wynik może warunkować przejście do kolejnych kroków. Flagi sterujące pozwalają zdefiniować, czy ostrzeżenia mają blokować build, ile problemów jest akceptowalnych i jak raportować wyniki (np. w formacie JUnit, Checkstyle, SARIF). W praktyce stosuje się też cache i równoległe wykonywanie dla przyspieszenia. Raporty można importować do systemów przeglądu kodu albo do platform bezpieczeństwa jako część skanów SAST.

W pracy na gałęziach przydają się pre-commit i pre-push hooki. Narzędzia takie jak husky, lint-staged czy lefthook pozwalają uruchomić ESLint tylko na zindeksowanych plikach, co skraca czas oczekiwania i ogranicza frustrację zespołu. Popularny schemat to: formater i linter w pre-commit, a kompletna analiza oraz testy w CI. Przy dużych repozytoriach i szczególnie w strukturze monorepo stosuje się narzędzia orkiestrujące zależności modułów i budowanie grafu zmian, by lintery uruchamiać selektywnie tylko tam, gdzie to konieczne.

Współpraca z innymi narzędziami wymaga odrobiny uwagi. Jeśli projekt używa aliasów ścieżek, warto dodać resolver do pluginu import, by uniknąć błędów w nawigacji i sortowaniu importów. Jeśli specyfika projektu narzuca nietypowe globalne zmienne, należy je zdefiniować w konfiguracji, by uniknąć fałszywych alarmów. Rozsądnie jest też wprowadzić reguły dla testów, osobny zestaw dla skryptów narzędziowych oraz dostosować reguły pod docelowe środowisko wykonania. Ta modularyzacja zapobiega „szumowi” ostrzeżeń i skupia uwagę na problemach realnych.

Scenariusze w praktyce: frameworki, testy i formatowanie

Projekty React korzystają zwykle z zestawu reguł dedykowanych dla JSX i hooków. Zasady te pilnują poprawnego porządku wywołań, zależności w listach efektów oraz czytelności komponentów. Dodatkowo reguły dostępności pomagają wychwycić brakujące etykiety, błędy w semantyce i problemy, które później mogłyby utrudnić korzystanie z aplikacji użytkownikom wspomagającym się technologiami asystującymi. Projekty Vue lub Svelte mają własne parsery i wtyczki, dostosowane do specyfiki plików szablonów i reaktywności. Angular wykorzystuje dedykowane rozszerzenia, które z kolei rozumieją pliki szablonów oraz wzorce specyficzne dla tego ekosystemu.

Środowisko Node wymaga uwzględnienia różnic między ESM a CommonJS, a także specyfiki wersji środowiska wykonawczego. W projektach serwerowych ważne są reguły dotyczące bezpieczeństwa – unikanie dynamicznej ewaluacji, walidacja danych wejściowych, ostrożne obchodzenie się z operacjami na ścieżkach i plikach. W testach z kolei używa się wtyczek dla frameworków testowych: zapewniają one kontrolę nad poprawnym użyciem asercji, czystością setupu/teardownu i semantyką testów. Dzięki temu testy pozostają wiarygodne i stabilne, a przypadkowe pomyłki (np. brak await) nie podważają zaufania do wyników.

W kwestiach formatowania powszechny jest podział obowiązków: formater dba o układ i interpunkcję, a ESLint o logikę i jakość. Taki układ redukuje konflikty, a także minimalizuje liczbę commitów modyfikujących wyłącznie layout. Typowy przepływ to: w edytorze automatyczne formatowanie przy zapisie, a następnie linter zgłaszający kwestie semantyczne. Użycie automatycznych poprawek lintera nie powinno kolidować z formaterem, jeśli wyłączy się odpowiednie reguły. W razie sporu pierwszeństwo oddaje się narzędziu do formatowania, tak aby zachować czytelność historii zmian i przewidywalność.

W miarę dojrzewania projektu rośnie liczba reguł i wyjątków. Dobrą praktyką jest uruchamianie narzędzia w trybie dry-run na oddzielnych gałęziach i ocenianie wpływu zmian reguł na rozmiar i znaczenie raportowanych problemów. Zespoły często decydują się na stopniowe zaostrzanie polityk: najpierw ostrzeżenia, potem błędy blokujące build. Daje to czas na adaptację i uniknięcie paraliżu rozwoju. Warto również stosować precyzyjne komunikaty commitów opisujące zmiany w zasadach – ułatwia to śledzenie historii decyzji jakościowych.

Własne rozszerzenia: pisanie reguł i praca z AST

Zaawansowani użytkownicy często tworzą własne reguły, aby odzwierciedlić unikatowe standardy firmy lub zautomatyzować wnioski z retrospektyw. Punktem wyjścia jest wybrany parser, który dostarcza reprezentację kodu do analizy, oraz struktura wtyczki, w której umieszcza się reguły wraz z dokumentacją, schematami opcji i testami. Reguła ma funkcję tworzącą i zwracającą zestaw odwiedzających dla klas węzłów w drzewie. Gdy odwiedzający natrafi na wzorzec wymagający interwencji, wywołuje raport z opisem problemu i – jeśli to bezpieczne – z funkcją naprawy. Dobrym zwyczajem jest udostępnienie testów z przypadkami pozytywnymi, negatywnymi i krawędziowymi.

Do budowy wtyczek przydatne są biblioteki pomocnicze i narzędzia do testowania reguł, które upraszczają konfigurację próbnych programów, oczekiwania co do komunikatów i zachowania fixerów. Warto też dokumentować intencję reguły i podawać przykłady, aby zachęcić zespół do korzystania i zgłaszania ulepszeń. Jeśli reguła ma być „type-aware”, np. w projektach TypeScript, konieczne jest włączenie usług parsera powiązanych z plikami projektu, co umożliwia wykorzystanie informacji typów w diagnozie. Pociąga to za sobą koszt wydajnościowy, ale pozwala wykrywać bardziej subtelne problemy.

Właściwe zrozumienie struktury AST ułatwia projektowanie reguł. Analiza węzłów, ich typów, atrybutów i relacji pozwala formułować precyzyjne kryteria i unikać fałszywych trafień. Dobrym wzorcem jest też konserwatywność fixerów: jeśli nie mamy pewności, że zmiana nie zmieni znaczenia kodu, lepiej ograniczyć się do raportu. Późniejsza ewolucja reguł może obejmować opcje konfiguracyjne pozwalające na lokalne kompromisy, bez rezygnowania z wartości zasad w całym projekcie.

Wydajność, bezpieczeństwo i migracje

W projektach o dużej skali kluczem jest wydajność. Tryby cache, równoległość i selektywna analiza tylko zmienionych plików istotnie skracają czas. W płaskiej konfiguracji łatwiej ograniczyć zakres działania reguł do konkretnych folderów, co eliminuje zbędną pracę. Należy też rozważnie dobierać reguły – te najbardziej kosztowne, operujące na wielu przebiegach lub wymagające informacji typów, powinny być używane tylko tam, gdzie przynoszą realną wartość. Dobrze jest okresowo mierzyć czas wykonywania i identyfikować wąskie gardła, np. za pomocą raportów z profilerów lub flag diagnostycznych narzędzia.

Aspekt bezpieczeństwa obejmuje zarówno reguły zapobiegające typowym błędom, jak i integracje z narzędziami skanującymi zależności i kod. Pluginy bezpieczeństwa potrafią sygnalizować niebezpieczne konstrukcje, ostrzegać przed użyciem niezaufanych danych w krytycznych API i wskazywać miejsca podatne na ataki. ESLint nie zastępuje pełnych skanerów bezpieczeństwa, ale stanowi pierwszą linię obrony i zmniejsza liczbę problemów widocznych na dalszych etapach. Regularne aktualizacje reguł bezpieczeństwa oraz przegląd wyjątków mają kluczowe znaczenie, by nie przyzwyczajać zespołu do ignorowania ostrzeżeń.

Migracje pojawiają się w kilku scenariuszach: przejście ze starego modelu konfiguracji do płaskiego, aktualizacje major wersji wtyczek, zmiany w platformie (np. wprowadzenie ESM), migracje językowe i narzędziowe. Dobrym sposobem jest podejście iteracyjne: najpierw przygotowanie gałęzi eksperymentalnej, włączenie nowych profili w trybie ostrzeżeń i dokładna analiza wpływu na repozytorium. Dopiero gdy zespół zrozumie skalę zmian i koszty, zaostrza się polityki. Warto też prowadzić listę znanych wyjątków z uzasadnieniem oraz planem spłaty długu – im bardziej przejrzyste reguły, tym większa akceptacja zespołu.

W aktualizacjach do nowszych wersji często dochodzi do zmian domyślnych zachowań. Dlatego dobrą praktyką jest przypinanie wersji krytycznych wtyczek, śledzenie changelogów i korzystanie z narzędzi automatyzujących podnoszenie wersji. Testy regresyjne dla konfiguracji (uruchamianie lintera na reprezentatywnych fragmentach kodu) pomagają wyłapać niepożądane efekty uboczne. Jeśli projekt korzysta z wielu pakietów, scentralizowane zarządzanie konfiguracją i wymuszanie zgodnych wersji zmniejszają ryzyko konfliktów i trudnych do reprodukcji błędów.

JavaScript, TypeScript i praca z frameworkami

ESLint analizuje kod JS w wielu wariantach – klasyczny, nowoczesny ESM, JSX – oraz może analizować TS poprzez alternatywny parser i dedykowane reguły. W przypadku TypeScript wyróżnia się dwa poziomy: reguły nieświadome typów (szybsze) oraz reguły świadome typów (dokładniejsze, wolniejsze), które wymagają wskazania plików projektu i włączenia usług parsera. Ten drugi tryb umożliwia wykrywanie subtelnych problemów typu błędne użycie przeciążeń, nieosiągalne gałęzie warunków czy nieprawidłowe zawężanie typów. W praktyce często łączy się oba podejścia, rezerwując reguły typowane dla krytycznych obszarów.

Frameworki front-end wprowadzają własne konwencje. React wymaga reguł dla komponentów, hooków i atrybutów JSX. Vue i Svelte mają parsery rozumiejące strukturę plików szablonów, dyrektyw i reaktywności. Angular korzysta z zestawów, które analizują zarówno kod, jak i szablony. Każdy z tych ekosystemów dostarcza własne rekomendowane prekonfiguracje i wtyczki, które warto traktować jako punkt wyjścia. Dzięki nim można uchwycić reguły najwyższej wartości dla danej technologii bez samodzielnego odkrywania pułapek. Dodatkowo dopełnieniem są reguły dostępności oraz testowe, utrzymujące spójność i jakość interfejsów użytkownika i testów jednostkowych.

Nie można pominąć importów i rozwiązywania modułów. Wtyczki i resolvery pomagają wykrywać błędne ścieżki, duplikaty, cykle oraz wymuszać kolejność i grupowanie importów. W rozbudowanych projektach aliasy katalogów i mapowania w configach bundlera wymagają synchronizacji z resolverami, aby ostrzeżenia miały sens i aby narzędzie rozumiało rzeczywistą strukturę zależności. W środowisku serwerowym nakładają się jeszcze kwestie wersji Node, różnic w ESM/CJS i specyficznych API – odpowiednia konfiguracja środowisk i parsera eliminuje szum i utrzymuje wykrywalność realnych błędów.

FAQ

Co to jest linting w kontekście ESLint? To statyczna analiza kodu mająca na celu wykrywanie błędów, niespójności i niebezpiecznych wzorców przed uruchomieniem programu. ESLint implementuje linting dla JavaScript/TypeScript i powiązanych dialektów, działając na drzewie składniowym i regułach, które można dostosować do potrzeb projektu.
Czy ESLint potrafi automatycznie naprawiać problemy? Tak, wiele reguł ma wbudowane autofixy. Uruchamiając linter z opcją naprawy, można skorygować znaczną część usterek bez ręcznej ingerencji. Fixery są ostrożne – zmieniają tylko to, co nie wpływa na znaczenie kodu.
Na czym polega konfiguracja płaska i dlaczego jest zalecana? Płaska konfiguracja przenosi ustawienia do pojedynczego pliku (eslint.config.js/mjs) i pozwala jasno definiować bloki reguł dla różnych wzorców plików. Ogranicza to dwuznaczności, poprawia wydajność i ułatwia zarządzanie w dużych repozytoriach.
Jakie są najpopularniejsze rozszerzenia? Zwykle spotyka się wtyczki dla React (react, react-hooks, jsx-a11y), importów, obietnic, bezpieczeństwa, testów i zaawansowanych praktyk. Dla TypeScript stosuje się parser i wtyczki z rodziny @typescript-eslint, co umożliwia analizę zarówno bez, jak i z informacją o typach.
Jak używać ESLint w CI? W pipeline’ach buduje się krok uruchamiający lintera na bazie wspólnej konfiguracji. Wyniki można raportować w formatach zrozumiałych dla systemu CI i ustawiać progi akceptowalnych ostrzeżeń. Warto włączyć cache i wykonywać analizę tylko dla plików zmienionych w commitach.
Czy ESLint zastępuje formater kodu? Nie. Najlepiej rozdzielić odpowiedzialności: formater odpowiada za layout i interpunkcję, a ESLint za semantykę, bezpieczeństwo i poprawność. Wyłączenie kolidujących reguł eliminuje konflikty i stabilizuje historię zmian.
Co daje analiza świadoma typów w TypeScript? Reguły korzystające z informacji typów wykrywają subtelniejsze błędy, ale są wolniejsze i wymagają konfiguracji projektu. Zwykle włącza się je wybiórczo, gdzie korzyści przewyższają koszt wydajnościowy.
Jak radzić sobie z wyjątkami i fałszywymi alarmami? Najlepiej korygować konfigurację i zakres reguł. Lokalnych wyłączeń w kodzie używa się oszczędnie, z komentarzem wyjaśniającym. Zbyt wiele wyjątków to sygnał, że zestaw zasad wymaga przemyślenia.
W jaki sposób pisać własne reguły? Tworzy się wtyczkę z definicjami reguł, dokumentacją i testami. Reguła odwiedza odpowiednie węzły drzewa i zgłasza problemy. Jeśli to bezpieczne, implementuje fixer. W projektach TS można skorzystać z usług parsera dla reguł świadomych typów.
Jak dopasować narzędzie do struktury monorepo? Stosować płaską konfigurację z blokami dopasowywanymi do wzorców, cache i selektywne uruchamianie na zmienionych pakietach. Warto także centralizować wspólne profile i wersje wtyczek dla spójności całej bazy kodu.