Inspect TypeScript AST without project setup

How to read the result

Start with diagnostics. If the parser reports a syntax error, a tree can still be produced, but some nodes may reflect parser recovery. Then inspect the AST tree and select the node that matches the problem: `FunctionDeclaration`, `InterfaceDeclaration`, `TypeAliasDeclaration`, `CallExpression`, `PropertyAccessExpression` or `Decorator`. The details panel shows numeric kind, `SyntaxKind`, ranges and the source slice. In TypeScript it is important to distinguish `pos`, `end` and `getStart`. `pos` often includes trivia such as whitespace and comments before a node, while `getStart` points to the first meaningful token. That matters for refactors and fixes, because a range that is too wide can remove comments or punctuation. The viewer shows both ranges so the decision is explicit. Compared with other approaches: Babel parser is excellent in the JS transformation ecosystem, but TypeScript compiler API provides native TS syntax and diagnostics. Regex is fine for one-off grep, but unsafe for structural changes. Manual inspection helps learning, but does not scale to production tooling. A practical workflow starts with small examples. If you are designing a lint rule, paste the smallest snippet that should be reported and compare it with a valid variant. For `typescript-eslint` work, the important discovery is often where the syntax tree differs from editor intuition: a function name can be a separate `Identifier`, the return type can be a separate `TypeNode`, and decorators or modifiers can live on arrays attached to a declaration. Clicking through the tree helps decide whether a rule should target a declaration, an expression, a type node or a specific token inside a larger structure. For codemods, safe ranges matter more than simply finding a node. If you plan to rewrite a function call, add an argument, change an import or expand a type alias, you need to know exactly which text range is safe to replace. You also need to see whether comments, commas or whitespace sit next to the node. The viewer makes that tradeoff visible. It separates structural intent from plain text replacement, reducing the chance that an automated refactor removes documentation comments, damages formatting or captures too much of the file. Parser diagnostics are just as important as the tree. TypeScript can recover a partial AST even when the source contains a syntax error. That behavior is useful for editors and live tools, but it can surprise automated tests. If a node looks unusual, check the diagnostics list, the error location and the source slice before blaming the compiler API or your traversal logic. The issue may be invalid input, parser recovery or an assumption in the tool you are building. The tool runs locally in the browser, so it is appropriate for quick experiments with private snippets, documentation examples or synthetic test fixtures. It does not replace full type-aware analysis with a project, `tsconfig` and a TypeScript program, but it gives a fast view of the syntax layer. When you need symbols, types, module resolution and import graphs, the next step is a local script built around `createProgram`. When syntax structure is enough, this viewer shortens the path from hypothesis to a working node selector.