Export status is answered in three places, two of them hand-mirrored regexes #1721

Three places in the codebase answer "is this name exported from this file", none of them shares an implementation, and they disagree about what counts.

isExported — the AST one. src/extraction/languages/typescript.ts:110-116 and javascript.ts:68 walk the parent chain for an export_statement ancestor. That is exact for export function f, and blind to everything else: const x = …; export { x } and every CommonJS form (module.exports, exports.x, exports["x"]) leave isExported false on the declaration's node.

isExportedLater — a regex, written because of that blindness. src/extraction/tree-sitter.ts:2368 runs one anchored regex over the file source for export default NAME / export { NAME }, and codegraph-kernel/src/tsjs/extractors.rs:301 mirrors it in Rust — two implementations that must be kept in step by hand, with only a doc comment saying so. Its single call site is the store-extraction condition at tree-sitter.ts:2843, so the fix it represents is scoped to Zustand stores rather than available generally.

A third, per-file, in the resolver. #1720 needs "does this file export anything at all" and cannot use either of the above — isExported would answer no for a CommonJS module, and isExportedLater answers a per-name question, not a per-file one. So it adds another source regex.

The result is that a CommonJS module's exports are invisible to the graph as exports, export { x } is visible only to store extraction, and the resolver re-derives a coarser version of the same fact from the same file text. Each site is individually defensible; together they mean the question has no single answer to point at, and the two regexes drift independently across a language boundary.

Worth considering: compute export status once during extraction — covering the export_statement ancestor, later export { … } / export default, and the CommonJS forms — and persist it on the node, with the per-file "exports nothing" fact derived from it. That would let #1720's guard read a stored fact instead of the file text, make CommonJS exports visible generally, and leave one implementation per language rather than two hand-mirrored regexes plus an AST walk.

Raising it as an issue rather than a PR because it touches extraction, the kernel and the resolver at once, changes what is persisted, and would want to be measured on a corpus the way the resolution changes have been — not something to fold into a PR already under review.