JavaScript: calls through a CommonJS destructured require are never resolved (express: 63 call edges from 11,733 call sites) #3778

Activity

1. BloodyBeard commented on Sep 23, 2026

   

   BloodyBeard

   on Sep 23, 2026

   Author

   More actions

   Narrowed this down further, and the root cause is upstream of the call binding: the calling function often has no node at all.

   lib/response.js contains 41 function declarations by tree-sitter's count, but graph.json has 11 nodes for that file. The pattern separating them is which object is assigned to:

   // lib/utils.js:61  -> node IS created
   exports.normalizeType = function(type){ ... };
   
   // lib/response.js:573  -> node is NOT created
   res.format = function(obj){ ... };

   Same syntactic form (<object>.<property> = function(){}), but only the exports. case produces a node. In express, res.*, req.* and app.* account for most of the public API.

   That explains the call-edge ratio rather than it being a separate defect: lib/response.js:587 calls normalizeType(key) from inside res.format, and since res.format has no node there is nothing for a calls edge to originate from. Fixing the declaration forms would likely recover most of the missing edges on its own.

   Worth noting the information is all present and literal — the imports edge for normalizeType resolves correctly, so the resolver already knows where the symbol lives.

   As a check on that theory: synthesizing the missing declarations from tree-sitter spans and then re-resolving call sites by name takes express from 11 to 165 calls edges, and produces exactly the expected res.format -> normalizeType() edge. Same treatment on other languages adds far less (Go's cobra: 0 synthesized nodes, since its declaration forms are fully captured), which is consistent with this being JS-specific rather than a general gap.
2. harshaygadekar commented on Oct 5, 2026

   

   harshaygadekar

   on Oct 5, 2026

   Contributor

   More actions

   I investigated the missing call edges in Express and other CommonJS codebases.

   Rca

   In Express, methods are attached to module objects before being exported (res.format = function(obj) { ... }; module.exports = res).

   In graphify/extractors/engine.py:

   1. _js_extra_walk only captured exports.x = fn and <Class>.prototype.x = fn. It intentionally ignored arbitrary obj.x = fn to prevent phantom god-nodes (Extraction noise: scope-blind identifier collision + over-eager markdown fragment nodes #1077).
   2. Because res.format was not recognized as a method node, its AST body was never appended to function_bodies.
   3. walk_calls never walked the body of res.format, meaning calls made inside it (such as normalizeType(...)) were never emitted or resolved to their imported functions.

   Solution

   1. Added _js_find_exported_objects() to identify top-level identifiers exported via CommonJS/ESM (module.exports = res, exports = module.exports = res, module.exports = { res }, etc.).
   2. In _js_extra_walk, when a member function is assigned to an exported object (owner_name in exported_names), we emit the method node and append its body to function_bodies so walk_calls extracts its internal call sites.
   3. Arbitrary unexported objects (const obj = {}; obj.whatever = () => 1;) remain ignored, preserving the Extraction noise: scope-blind identifier collision + over-eager markdown fragment nodes #1077 guard.

   All JS unit tests and the reproduction case pass. opened the PR.
3. harshaygadekar

   added a commit that references this issue on Oct 5, 2026

   fix(js): extract methods on exported objects to resolve CommonJS/ESM …

   ...

   65f2da5
4. safishamsi

   added a commit that references this issue on Oct 5, 2026

   fix(js): extract methods on exported objects to resolve CommonJS/ESM …

   ...

   5c5ce7f
5. safishamsi commented on Oct 5, 2026

   

   safishamsi

   on Oct 5, 2026

   Member

   More actions

   Resolved by #4121 (thanks @harshaygadekar), shipped in v0.9.77. Closing as fixed.
6. safishamsi

   closed this as completedon Oct 5, 2026