fix(cli): distinguish zero exports from an unbuilt graph in exports <file> - #2582
Merged
Conversation
…file> exportsData conflated "no file-kind node matched at all" (unbuilt/not-found) with "the file is in the graph but legitimately has zero exports" (entry script, side-effect-only module) -- both produced results.length === 0, so fileExports told the user to rebuild even on a correctly built graph. exportsData now also returns fileFound, true whenever a file-kind node matched regardless of its export count. The CLI uses it to print "No exported symbols found for X." without the rebuild suggestion whenever the file was actually found, mirroring the fix applied to roles --role in #2390. docs check acknowledged Closes #2530 Impact: 3 functions changed, 2 affected
Contributor
Greptile SummaryThe PR now distinguishes an indexed file with zero exports from a file absent from the graph, while tightening fuzzy file selection to avoid unrelated substring collisions.
Confidence Score: 5/5The PR appears safe to merge. No blocking failure remains. Important Files Changed
Reviews (7): Last reviewed commit: "fix: exports treats no-plausible-match a..." | Re-trigger Greptile |
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
Contributor
Codegraph Impact Analysis4 functions changed → 3 callers affected across 3 files
|
…ring hit findFileNodes uses LIKE '%target%', so a nonexistent target could mid-string-collide with an unrelated file's path (e.g. "add.js" matching "badd.jsx", or "utils.js" matching "my-utils.js") and set fileFound: true for a file the caller never actually asked about, suppressing the rebuild suggestion when it was still warranted. fileFound now requires an exact match or a "/"-bounded path suffix via isPlausibleFileMatch. docs check acknowledged Impact: 2 functions changed, 3 affected
Contributor
Author
…esult findFileNodes has no ORDER BY, so when a target ambiguously LIKE-matches multiple files, fileResults[0] was whichever row SQLite's unordered scan happened to visit first. If an unrelated mid-string collision was inserted before the genuine exact/suffix match, it would win, showing the wrong file's (possibly empty) data and reporting fileFound: false even though a real match existed elsewhere in the result set. exportsData now prefers the first fileResults entry that isPlausibleFileMatch accepts, falling back to the first result only when no candidate is plausible. docs check acknowledged Impact: 1 functions changed, 2 affected
Contributor
Author
… default SQLite's LIKE is case-insensitive for ASCII by default, so a case-mismatched target (e.g. "Entry.js" against a stored "entry.js") already passes the LIKE '%target%' lookup used throughout this module. isPlausibleFileMatch's own exact/suffix comparison was case-sensitive, making it stricter than the lookup that decided the match was a hit in the first place -- reintroducing a false "file not found" for a spelling variant SQLite itself already accepted. Both sides are now lowercased before comparing. docs check acknowledged Impact: 1 functions changed, 3 affected
Contributor
Author
…Found Two related gaps in the fuzzy file-match selection: - fileFound could be false while first.results was non-empty (a real collision file with real exports, but no plausible candidate at all) -- a self-contradictory signal for structured/JSON consumers even though the CLI's own text messaging never reads fileFound once results are non-empty. fileFound is now also true whenever first has real results or reexports. - isPlausibleFileMatch's case-insensitivity (needed to match SQLite LIKE's own default behavior) meant two distinct real files differing only by case could both look plausible for the same target, and the unordered LIKE scan could return the wrong one. exportsData now prefers an exact (case-sensitive) match via isExactFileMatch before falling back to the case-insensitive check. docs check acknowledged Impact: 2 functions changed, 3 affected
Contributor
Author
… fallback The previous fix (hasContent) resolved the fileFound/non-empty-results contradiction by making fileFound true whenever an unordered fallback still had real content -- but that fallback could be an entirely unrelated substring collision, so a missing target could still surface a different file's real exports under fileFound: true. Requiring a plausible candidate (isExactFileMatch or isPlausibleFileMatch) to exist at all, and treating its absence exactly like fileResults.length === 0, removes the arbitrary fallback entirely: nothing plausible now means nothing is returned, full stop, matching a genuinely missing file's behavior. fileFound is then trivially always true once `first` exists, since it can only exist when one of those checks already accepted it. docs check acknowledged Impact: 1 functions changed, 2 affected
Contributor
Author
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
codegraph roles --role <X>conflating "the graph has no classified symbols at all" with "this filter matched nothing." bug(cli):codegraph exports <file>says "Run codegraph build first" for a file that legitimately has zero exports #2530 identifies the same conflation incodegraph exports <file>.src/domain/analysis/exports.ts'sexportsDatareturned the exact same shape (results: [], all totals zero) whether a file'sfile-kind node was never found in the graph at all (unbuilt/nonexistent file) or the file was found but simply has zero exports (e.g. an entry script, a side-effect-only module, or a file that only re-exports viaexport *).fileExports's single "No exported symbols found... Runcodegraph buildfirst." branch, which is misleading on a correctly built graph.exportsDatanow also returnsfileFound: boolean—truewheneverfindFileNodesmatched afile-kind node for the target, independent of its export count.fileExportsuses it to printNo exported symbols found for "<file>".(no rebuild suggestion) whenever the file was actually found, mirroring the pattern bug(cli): roles --role <X> with zero matches says "Run codegraph build first" on a fully-built graph #2390 used withtotalClassified.Closes #2530
Test plan
tests/integration/exports.test.ts: added aentry.jsfixture file (a file-kind node with a non-exported function, simulating an entry script) and a new test assertingfileFound: truewith zero exports; updated the existing "unknown file" test to assertfileFound: false.tests/presentation/queries-cli.test.ts: split the old single "no exports found" test into two — one confirming the rebuild suggestion still appears whenfileFound: false, one confirming it's absent whenfileFound: true.data.fileFoundbranch and confirmed the new "does not recommend a rebuild..." test fails with the exact pre-fix message; restored the fix and it passes again.codegraph diff-impact --staged -T: 3 functions changed, 2 transitive callers affected — contained blast radius, no unexpected consumers.npm run lintclean.npx vitest run: 5520/5520 tests pass (344 test files, +2 new).