01Czytaj parser output zanim napiszesz regule ESLint
typescript-eslint Parser Playground (Learning Mode) powstal jako osobny krok po ESLint Rule Tester, bo autor reguly często musi najpierw zrozumiec ksztalt AST, a dopiero potem pisac testy valid i invalid. Strona pozwala wkleic maly snippet TypeScript, TSX albo JavaScript i zobaczyc drzewo nodeow, ranges, line/column, parent path oraz selector hint. Kod zostaje w przeglądarce, a wynik sluzy do dyskusji o tym, jaki node naprawde nalezy obserwowac w listenerze reguly. To obniza koszt review: zamiast zgadywac, czy selector ma lapac interface, type reference, JSX element albo call expression, mozna wskazac konkretny node i jego ścieżkę.
02Co robi MVP i dlaczego jest oznaczone jako learning mode
Plan zaczynal od browserowego gate dla realnego @typescript-eslint/parser. Spike pokazal, ze pelny bundle parsera wciaga zaleznosci Node-only, wiec zgodnie z zatwierdzonym fallbackiem MVP używa TypeScript compiler API i mapuje najwazniejsze node kind na ESTree-like nazwy przydatne autorowi reguly. UI nie udaje pelnej zgodnosci parsera: pokazuje etykiete ESTree-like learning mode, brak projectService, brak parserServices, brak tsconfig filesystem context i brak uruchamiania regul ESLint. To jest celowy kompromis produktowy. Uzytkownik dostaje realne parsowanie tekstu, diagnostics i selector hints, ale nie dostaje falszywej obietnicy type-aware lintingu w publicznym browserze.
03Jak wykorzystac wynik w praktyce
Najpierw wybierz preset, który przypomina problem: interface/generic type dla kontraktow typow, TSX component dla JSX i props, parser diagnostic dla błędów skladni albo selector sample dla call expression i object expression. Po parsowaniu kliknij node w drzewie i sprawdź type, kind, range, loc, parent path oraz selector. Selector hint typu TSInterfaceDeclaration albo CallExpression jest punktem startowym dla listenera reguly, a parent path pomaga rozstrzygnac, czy interesuje Cie sam node, jego rodzic, czy szerszy pattern. Diagnostics pokazuja, gdzie parser zatrzymuje się na blednym kodzie; to przydatne przy przygotowywaniu komunikatow dla użytkowników reguly i przy odroznianiu błędu skladni od błędu samej reguly. Limity są jawne: 50 000 znakow inputu, 5 000 nodeow, depth 64 i timeout workera 4 000 ms. Dzięki temu strona pozostaje responsywna nawet przy wiekszych probkach, a wynik z przycieciem jest oznaczony jako truncated. Kiedy selector i ksztalt AST są juz jasne, dalszy krok powinien prowadzic do ESLint Rule Tester Playground albo do oficjalnego @typescript-eslint/rule-tester w repozytorium. Tam dopiero walidujesz messageId, valid/invalid fixture, autofix output i semantyczne zaleznosci projektu. Publiczny playground ma skrocic faze rozumienia AST, a nie zastapic CI ani testow produkcyjnych.
Dla SEO i użytkownika ważne jest też to, ze strona nie zatrzymuje się na samym widgetcie. Tlumaczy różnice miedzy ESTree-like shape, surowym TypeScript AST i pelnym parserem typescript-eslint. Osoba trafiajaca z wyszukiwarki może zrozumiec, dlaczego node type w listenerze nie zawsze odpowiada nazwie SyntaxKind, dlaczego diagnostics parsera są inne niz naruszenia reguly i dlaczego selected node powinien byc traktowany jako punkt startowy, a nie gotowy dowod produkcyjny. Ten kontekst ogranicza ryzyko blednego uzycia narzędzia: publiczny parser playground pomaga wyjasnic ksztalt kodu, natomiast decyzja o rollout reguly wymaga jeszcze fixture, dokumentacji reguly i CI w repozytorium.
Przy wiekszych fragmentach kodu użytkownik powinien redukowac input do najmniejszego reprodukowalnego przykladu. To zwykle daje lepszy wynik niz wklejanie calego pliku, bo selector rule authoring rzadko zalezy od setek linii otoczenia. Jesli szukasz node dla type alias, zostaw type alias i jeden usage. Jesli szukasz JSX handlera, zostaw komponent, props type i jedno wywolanie funkcji. Jesli diagnostic jest celem testu, zostaw tylko minimalny błąd skladni. Taki sposob pracy daje czystszy parent path, mniej szumu w drzewie i latwiejsza rozmowe z reviewerem.
Granica fallbacku jest jawna również biznesowo. Pelny @typescript-eslint/parser ma sens w kontrolowanym środowisku z zaleznosciami Node, wersjami paczek i projektem tsconfig. Publiczny Playground Forge ma byc szybki, prywatny i indeksowalny, wiec nie rozszerza CSP, nie pobiera zdalnych importow i nie tworzy backendowego sandboxa bez osobnego taska. Dzięki temu narzędzie jest uczciwe: daje wartość edukacyjna teraz, a bardziej kosztowny runtime może powstac pozniej jako osobny produkt, jesli dane z ruchu i zapytan pokaza realna potrzebe.
W praktyce taki content pomaga również osobom, które dopiero ucza się custom lintingu. Mogą porownac te sama skladnie w trzech narzedziach: tutaj zobaczyc rule-authoring shape, w TypeScript AST Viewer zobaczyc compiler SyntaxKind, a w ESLint Rule Tester sprawdzić zachowanie reguly na fixture. To tworzy spojna ścieżkę edukacyjna w katalogu Playground Forge i wzmacnia klaster tematyczny TypeScript/ESLint bez mnozenia pustych stron. Kazdy playground ma inna odpowiedzialnosc, a użytkownik widzi, kiedy ktorego uzyc.
Dodatkowo tekst celowo opisuje ryzyka fallbacku prostym jezykiem: wynik jest przydatny do nauki i wstepnego projektowania reguly, ale nie jest certyfikatem zgodnosci z pelnym parserem. Taka transparentnosc jest ważna dla zaufania i dla jakosci strony wydawcy.