01Read parser output before writing an ESLint rule
typescript-eslint Parser Playground (Learning Mode) is a separate step after ESLint Rule Tester because a rule author often has to understand AST shape before writing valid and invalid tests. The page accepts a small TypeScript, TSX or JavaScript snippet and returns a node tree, ranges, line/column positions, parent path and selector hint. Code stays in the browser, and the result supports a concrete discussion about which node a rule listener should observe. That lowers review cost: instead of guessing whether a selector should target an interface, a type reference, a JSX element or a call expression, the reviewer can point to a specific node and its path.
02What the MVP does and why it is labeled as learning mode
The plan started with a browser gate for the real @typescript-eslint/parser. The spike showed that the full parser bundle pulls Node-only dependencies, so the approved fallback uses the TypeScript compiler API and maps important node kinds into ESTree-like names useful for rule authors. The UI does not pretend to be full parser parity: it displays an ESTree-like learning mode label, no projectService, no parserServices, no tsconfig filesystem context and no ESLint rule execution. This is a deliberate product tradeoff. Users get real text parsing, diagnostics and selector hints, but they do not get a false promise of type-aware linting inside a public browser page.
03How to use the output in practice
Start with the preset that resembles the problem: interface/generic type for type contracts, TSX component for JSX and props, parser diagnostic for syntax failures or selector sample for call expressions and object expressions. After parsing, click a node in the tree and inspect type, kind, range, loc, parent path and selector. A selector hint such as TSInterfaceDeclaration or CallExpression is the starting point for a rule listener, while the parent path helps decide whether the rule cares about the node itself, its parent or a broader pattern. Diagnostics show where the parser stops on broken code; that is useful when preparing user-facing rule messages and separating syntax problems from rule behavior. Limits are explicit: 50,000 input characters, 5,000 nodes, depth 64 and a 4,000 ms worker timeout. This keeps the page responsive for larger snippets, and truncated output is labeled. After the selector and AST shape are clear, the next step should be ESLint Rule Tester Playground or official @typescript-eslint/rule-tester in a repository. That is where messageId, valid/invalid fixtures, autofix output and project-level semantic dependencies belong. The public playground shortens AST understanding; it does not replace CI or production tests.
For SEO and for users, the page also needs to be more than a widget. It explains the difference between ESTree-like shape, raw TypeScript AST and the full typescript-eslint parser. A visitor coming from search can understand why a listener node type does not always match a SyntaxKind name, why parser diagnostics are different from rule violations and why a selected node should be treated as a starting point rather than production proof. That context reduces misuse: the public parser playground explains code shape, while a rule rollout still needs fixtures, rule documentation and CI in the repository.
For larger snippets, users should reduce input to the smallest reproducible example. That usually gives a better result than pasting a full file because selector rule authoring rarely depends on hundreds of surrounding lines. If you need a node for a type alias, keep the alias and one usage. If you need a JSX handler, keep the component, props type and one function call. If a diagnostic is the target, keep only the minimal syntax error. This workflow produces a cleaner parent path, less tree noise and a better conversation with reviewers.
The fallback boundary is also a business decision. The full @typescript-eslint/parser belongs in a controlled environment with Node dependencies, package versions and tsconfig project context. Public Playground Forge must stay fast, private and indexable, so it does not loosen CSP, load remote imports or create a backend sandbox without a separate task. That keeps the tool honest: it delivers educational value now, while a more expensive runtime can become a separate product later if traffic and query data show real demand.
In practice, this content also helps people who are still learning custom linting. They can compare the same syntax across three tools: this page for rule-authoring shape, TypeScript AST Viewer for compiler SyntaxKind and ESLint Rule Tester for rule behavior against fixtures. That creates a coherent educational path inside the Playground Forge catalog and strengthens the TypeScript/ESLint topic cluster without creating thin pages. Each playground has a separate responsibility, and the user can see when to use each one.