forwardRef components get no JSX render edges — callers/impact silently return empty

[Arlandaren]

Version: 0.9.9 (linux x64, node:sqlite backend)
Language: TypeScript/TSX (Turborepo monorepo, ~490 indexed files)

Summary

Components declared as const X = React.forwardRef(...) are indexed as
constant nodes, and no render/call edges are created for their JSX
usages (<X ...>). As a result codegraph_callers / codegraph_impact
return "No callers found" for any shadcn/ui-style component, even when
dozens of files render it.

Function-declared components are fine: for export function ThemeProvider()
the JSX render edges exist and callers are reported correctly. The problem
is specific to the declaration style.

Repro

// packages/ui/src/button.tsx
import * as React from "react";
export const Button = React.forwardRef<
  HTMLButtonElement,
  React.ButtonHTMLAttributes<HTMLButtonElement>
>((props, ref) => <button ref={ref} {...props} />);
Button.displayName = "Button";

// apps/web/page.tsx
import { Button } from "../../packages/ui/src/button";
export function Page() {
  return <Button>Click</Button>;
}
codegraph init -i
codegraph callers Button
Expected: Page (function) — apps/web/page.tsx
Actual: No callers found for "Button"

Also observed:

codegraph_search with kind: "component" does not return Button at all (it only exists as a constant node).
The import { Button } ... edges ARE indexed, so the data loss is only in the render/call edge extraction, not in import tracking.
Real-world impact
In our monorepo is rendered in 81 files across 3 apps
(verified with grep), yet codegraph_callers Button and
codegraph_impact Button report nothing. This is a dangerous silent false
negative: "no callers" reads as "safe to change" right before a refactor of
a design-system component. Every shadcn/ui component uses the
const X = React.forwardRef(...) pattern, so for typical React design
systems the entire UI layer is invisible to impact analysis.

Likely related (untested): React.memo(...), styled(...) and other
HOC-wrapped const components.

Suggested fix

Treat const X = React.forwardRef(...) / React.memo(...) initializers as
component declarations in the tree-sitter extraction queries (kind:
component), and emit the same JSX render edges that function-declared
components get.

For comparison: function-declared components in the same codebase resolve
correctly through barrel re-exports and workspace aliases (@repo/ui), so
the resolution layer itself looks solid — it's only the component
recognition for wrapped declarations that's missing.

[maxmilian]

Root-caused this — I'd like to take it.

The React framework resolver (reactResolver) already has regex-based component detection for forwardRef/memo/arrow components, but its languages list is ['javascript', 'typescript'] and does not include 'tsx'/'jsx'. Since .tsx/.jsx files are detected as language tsx/jsx, getApplicableFrameworks() filters the React resolver out of the extraction pass for exactly those files — so its extract() never runs and no component node is ever synthesized for const X = forwardRef(...).

At resolution time, the <Button> render reference reaches resolveComponent(), but getNodesByName('Button') only returns the tree-sitter constant node, which COMPONENT_KINDS = {component, function, class} filters out → return null → no render edge. This also explains the asymmetry: export function ThemeProvider() works because tree-sitter emits a function node (which is in COMPONENT_KINDS), while const X = forwardRef/memo/arrow only gets a constant node.

Fix is to include tsx/jsx in the resolver's applicable languages so the existing component-detection path actually fires for those files. Will open a PR with a regression test shortly.

[colbymchenry]

Fixed — landing in the next release.

Components declared with forwardRef, memo, or styled-components/emotion are now recognized as component nodes (in the tree-sitter extractor, with their body and callees captured), so <Button/> usages link back and callers / impact are complete — no more "No callers found" on a rendered shadcn/ui-style component. They also show up under a component search now.

While fixing the underlying cause — the React resolver was being filtered out of .tsx/.jsx extraction, so its component detection never ran on the files components actually live in — we also restored React Router / Next.js route indexing on JSX files, which had the exact same root cause.

Validated before/after on real repos: shadcn/taxonomy went 0 → 99 component nodes (35 with callers), radix-ui/primitives 0 → 262 (80 with callers), with the graph node count stable and a non-React control unchanged.

Thanks @Arlandaren for the clear, well-reproduced report, and @maxmilian for the spot-on root-cause analysis (#846).