Skip to content

fix(argent): declare + ship tree-sitter so react-profiler-component-source finds components#287

Draft
latekvo wants to merge 1 commit into
mainfrom
fix/component-source-tree-sitter-deps
Draft

fix(argent): declare + ship tree-sitter so react-profiler-component-source finds components#287
latekvo wants to merge 1 commit into
mainfrom
fix/component-source-tree-sitter-deps

Conversation

@latekvo

@latekvo latekvo commented Jun 1, 2026

Copy link
Copy Markdown
Member

Problem

react-profiler-component-source returns { found: false } for every component in a standard TypeScript/Expo project. Reproduced live against the published @swmansion/argent@0.9.0 for three components that genuinely exist:

  • PokemonExploreEntryexport default function PokemonExploreEntry(...)
  • ExploreScreenexport default function ExploreScreen()
  • StatBar — plain function StatBar(...) returning JSX

Each lookup returned in 1–3 ms (too fast to have walked the tree), and the result message — not found in <root> — actively misleads (it reads as "the component doesn't exist").

Root cause

The bundled tool-server resolves the parser at runtime via _require("tree-sitter") / _require("tree-sitter-typescript") (utils/react-profiler/pipeline/06-resolve/ast-index.ts). Both are native addons (ship a .node binary), so esbuild leaves them as runtime externals — but the published package declares neither as a dependency, so the require throws, is swallowed by loadTreeSitter()'s try/catch, and buildAstIndexWithDiagnostics returns an empty index with treeSitterAvailable: false before reading a single file. astIndex.index.get(name) is then always undefinedfound: false.

The grammar/match logic itself is correct. The bug is invisible in the dev monorepo (which has tree-sitter present) and only bites installs of the published package — which is why it shipped.

Fix

  1. Declare tree-sitter + tree-sitter-typescript in @swmansion/argent's dependencies so they install alongside the package.
  2. Mark them external in the tool-server esbuild bundle (esbuild can't inline .node addons) — explicit and robust.
  3. Stop misreporting genuine-miss vs parser-unavailable: when treeSitterAvailable is false, return a clear "tree-sitter parser could not be loaded" message; on a real miss, include the indexed-file count. This would have surfaced the packaging gap immediately.

Testing

  • Live (fail-before): against published 0.9.0, the three real components above all returned found: false.
  • Grammar (first-hand): with the pinned pair installed, the exact ast-index match logic parses all three forms — Foo (export default function), Bar (plain function), Baz (arrow const) — hasError: false.
  • Unit: adds test/react-profiler/ast-index.test.ts (there were no ast-index tests). It builds the index over a fixture .tsx and asserts treeSitterAvailable === true plus the three components at the right lines. vitest run → passes with tree-sitter present; the treeSitterAvailable assertion fails loudly if the parser dependency goes missing again.

…s components

react-profiler-component-source returned found:false for every component in a standard TS/TSX project. The bundled tool-server require()s "tree-sitter" and "tree-sitter-typescript" (native addons) at runtime, but the published @swmansion/argent declared neither as a dependency, so the require threw, was swallowed by loadTreeSitter()'s try/catch, and the AST index was always empty. The grammar/match logic was already correct — the pinned pair parses export-default-function, plain-function, and arrow components.

Declare both as dependencies and mark them external in the tool-server esbuild bundle (esbuild can't inline .node addons). Also stop misreporting "<name> not found in <root>" when the parser failed to load — surface a clear "tree-sitter parser could not be loaded" message (and the indexed-file count on a genuine miss), which would have made this packaging gap obvious.

The bug is invisible in the dev monorepo (which has tree-sitter present) and only affects installs of the published package.
@latekvo latekvo force-pushed the fix/component-source-tree-sitter-deps branch from e7331a1 to e203511 Compare June 3, 2026 15:09
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant