222af6b87c
A NestJS-style monorepo has one UserService/UserModule/UserRepository per app; with no package concept for TS they share one global name scope and agents visibly warned that CodeGraph was mixing unrelated classes. Two distinct problems, two fixes: 1. TOOL AGGREGATION. callers/callees returned one merged list across every same-named match, and impact merged all their blast radii into a single overstated subgraph. Now: matches group into DISTINCT DEFINITIONS (filePath + qualifiedName — same-file overloads still merge, that's the overload feature) and render one file-labeled section per definition; a new `file` argument (path or suffix, like codegraph_node's) narrows to one definition, suppressing the stale aggregation note; a non-matching `file` falls back to all definitions with a note. server-instructions documents the behavior. 2. RESOLUTION WRONG EDGES. Auditing a real monorepo (amplication, 54k nodes) found 1,036 cross-package `references` edges into duplicated names. Root cause: the React framework resolver ran PascalCase component resolution on refs from PLAIN .ts FILES (a GraphQL types file's own `Account` type alias lost to an arbitrary same-named CLASS in another package — the resolver's blind `components[0]` fallback at confidence 0.8 outranked the name-matcher's proximity-correct 0.7). Component resolution is now gated to JSX-capable refs (tsx/jsx) and never guesses among multiple candidates without a positional signal (same-dir / component-dir / unique). Cross-package wrong edges: 1,036 -> 40 (-96%; the remainder are genuine shared-model imports and codegen template scaffolds), with the freed refs re-resolving to the correct same-file/same-package targets. excalidraw (a real React repo) is a zero-delta control — legitimate component refs all carry same-dir/component-dir signals. Graph-level separation was verified correct on a fixture before any changes (import + proximity resolution keeps apps apart) — the conflation was tool-level plus the react-resolver edge class. Tests: 6-test e2e suite (grouped callers/callees, per-definition impact radii, file narrowing, fallback note, cross-app edge isolation) + react resolver unit tests updated to production reality (tsx refs resolve, plain-ts refs decline). Full suite 1398 passed. EXTRACTION_VERSION 23 -> 24 (re-index to drop the wrong cross-package edges). Closes #764 Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
25 lines
1.3 KiB
TypeScript
25 lines
1.3 KiB
TypeScript
/**
|
|
* Extraction version
|
|
*
|
|
* A monotonically-increasing integer that identifies the *shape and depth* of
|
|
* what the extractor writes into the graph. Unlike `CURRENT_SCHEMA_VERSION`
|
|
* (which tracks the SQLite table layout and is migrated in place), this tracks
|
|
* the EXTRACTED CONTENT — node kinds, edges, synthesizers, resolver coverage.
|
|
*
|
|
* When an index was built by an older engine whose `EXTRACTION_VERSION` is
|
|
* below the running engine's, the data on disk is structurally fine but
|
|
* *stale*: it's missing whatever a newer extractor would now produce. A schema
|
|
* migration can't backfill that — only a re-index can. So this is the signal
|
|
* `codegraph status` uses to recommend a re-index, and the reason `codegraph
|
|
* upgrade` reminds users to refresh their projects.
|
|
*
|
|
* BUMP THIS when a release changes extraction output enough that existing
|
|
* indexes should be rebuilt to benefit — e.g. a new language/framework
|
|
* extractor, a new dynamic-dispatch synthesizer, a new node/edge kind, or a
|
|
* resolver fix that materially changes which edges exist. Do NOT bump for
|
|
* pure bug fixes, CLI/UX changes, or schema-only migrations. Over-bumping
|
|
* turns the re-index hint into noise — keep it honest (see CLAUDE.md, "Honesty
|
|
* in the product is load-bearing").
|
|
*/
|
|
export const EXTRACTION_VERSION = 24;
|