Testuj customowe reguly ESLint w przegladarce

Jak czytac wynik

Zielony run oznacza, ze obecny zestaw snippetow pasuje do zachowania reguly zadeklarowanego w fixture. Nie oznacza, ze regula jest gotowa produkcyjnie dla kazdej opcji parsera, kazdego pakietu w monorepo albo kazdego frameworkowego ksztaltu AST. Zacznij od jednego przypadku valid i jednego invalid, a potem dodaj fixture TypeScript, jesli regula dotyka adnotacji typow, TSTypeReference, importow, enumow albo generykow. Fail traktuj jako feedback kontraktowy: mismatch messageId zwykle wskazuje meta.messages albo konfiguracje report; mismatch typu node oznacza za szeroki albo za waski selector; mismatch output pokazuje, ze zakres fixera lub tekst zamiany trzeba uproscic przed rolloutem. Playground blokuje siec i storage APIs w workerze, limituje rozmiar inputu i ubija długie runy, ale nadal jest powierzchnia wykonywania krótkich syntetycznych regul, a nie sandbox security dla niezaufanych paczek. Uzywaj malych przykladow, nie wklejaj poufnego kodu i przenies finalna regule do testow repozytorium z oficjalnym ESLint RuleTester przed wdrozeniem. Tresc wydawcy na tej trasie jest celowo glebsza niz sam widget: wyjasnia granice parsera, projektowanie fixture, ryzyka autofix, zachowanie timeoutow i powod, dla ktorego type-aware projectService jest poza client-side MVP. Praktyczne review powinno obejmowac takze ergonomie reguly. Sprawdz, czy komunikat mowi developerowi co ma zmienic, czy invalid example przypomina realny kod oraz czy autofix bylby bezpieczny w duzym pull requescie. Dobra regula lintowania zmniejsza liczbe powtarzalnych komentarzy review, a nie tworzy nowej niejasnosci. Dlatego playground pokazuje wynik per case: przechodzace przyklady valid dowodza, ze regula nie jest zbyt glosna, failing invalid examples pokazuja, czy selector znalazl zamierzona skladnie, a porownanie output ujawnia ryzyko fixera zanim regula trafi do wspolnego presetu. Tryb parsera TypeScript jest przydatny dla polityk skladniowych dotyczacych importow, type alias, generic references, enumow i niebezpiecznych wzorcow nazw. Nie zastepuje parserServices, zapytan do type checkera ani project references. Jesli regula potrzebuje symbol resolution, semantycznej informacji o typach, swiadomosci module graph albo zachowania zależnego od tsconfig, bezpiecznym kolejnym krokiem jest test suite w docelowym repozytorium. Ta granica jest ważna dla zaufania: publiczna trasa może pokazac ksztalt reguly i projekt fixture, a CI pozostaje odpowiedzialne za pelny kontekst zaleznosci, zgodnosc z oficjalnym RuleTester i framework-specific edge cases. Trzy presety traktuj jako szablony decyzji. Przyklad identyfikatora sluzy do kontraktu message i szumu selectora. Przyklad ReadonlyArray sluzy do slownika TypeScript AST bez semantycznych type services. Przyklad debugger sluzy do options, jezyka schema i konserwatywnych fixow. Kiedy zespol proponuje nowa regule lintowania, najpierw mapuj ja do jednego z tych wzorcow, a dopiero potem dodaj najmniejsza dodatkowa fixture potrzebna do udowodnienia zachowania. Ten nawyk utrzymuje dyskusje o regulach konkretnie i nie pozwala, żeby publiczny playground stal się nieudokumentowanym frameworkiem lintowania. W praktyce najwieksza wartość biznesowa takiego narzędzia pojawia się przed wdrozeniem reguly do wielu repozytoriow. Reviewer może szybko zobaczyc, czy regula ogranicza realny koszt utrzymania kodu, czy tylko dodaje nowy obowiazek. Jesli fixture nie potrafia jasno pokazac problemu i oczekiwanej poprawki, sama regula prawdopodobnie wymaga jeszcze doprecyzowania. Dzieki temu decyzja o rollout jest latwiejsza do obrony: widac koszt, zysk, ograniczenia i miejsce, w którym publiczny eksperyment musi przejsc do testow repozytorium. Konkret.