Deferred from PR #2141 review.
Original reviewer comment: Greptile summary body — #2141 (comment)
Context: exportJSON in src/features/export.ts produces edges with a different source/target schema depending on opts.fileLevel:
- File-level (
fileLevel: true, default): edges[].source/target are file path strings (n1.file AS source, n2.file AS target), which don't even match the file-level nodes[].id numeric field in the same payload.
- Function-level (
fileLevel: false, --functions): edges[].source/target are numeric node IDs (e.source_id/e.target_id), which do match nodes[].id.
Greptile flagged this as "a minor API inconsistency in new code with no existing consumers" (Confidence Score 5/5, not blocking). The function-level behavior is actually the more internally-consistent one (edges reference nodes[].id), but changing the file-level behavior to match would be a breaking change to the existing codegraph export -f json output shape, which has existing consumers today — out of scope for PR #2141, whose mandate is narrowly to fix the --functions flag being ignored for json/graphson formats.
Suggested follow-up: Decide on a consistent identifier scheme for exportJSON edges across both levels (e.g. always key edges by nodes[].id, keeping file paths only as a display property), and version/document the change since it affects the public JSON export shape.
Deferred from PR #2141 review.
Original reviewer comment: Greptile summary body — #2141 (comment)
Context:
exportJSONinsrc/features/export.tsproduces edges with a differentsource/targetschema depending onopts.fileLevel:fileLevel: true, default):edges[].source/targetare file path strings (n1.file AS source, n2.file AS target), which don't even match the file-levelnodes[].idnumeric field in the same payload.fileLevel: false,--functions):edges[].source/targetare numeric node IDs (e.source_id/e.target_id), which do matchnodes[].id.Greptile flagged this as "a minor API inconsistency in new code with no existing consumers" (Confidence Score 5/5, not blocking). The function-level behavior is actually the more internally-consistent one (edges reference
nodes[].id), but changing the file-level behavior to match would be a breaking change to the existingcodegraph export -f jsonoutput shape, which has existing consumers today — out of scope for PR #2141, whose mandate is narrowly to fix the--functionsflag being ignored forjson/graphsonformats.Suggested follow-up: Decide on a consistent identifier scheme for
exportJSONedges across both levels (e.g. always key edges bynodes[].id, keeping file paths only as a display property), and version/document the change since it affects the public JSON export shape.