fix: TS/JS object-literal repository methods get their own graph node

[nn-tmg]

Fixes #2110.

What's broken

const repo = { findX(...) {...}, y: async () => {...} } at module scope produces exactly one graph node — for repo itself — and nothing for its methods. Every call into or out of such a method is invisible to affected/explain/the call graph.

This hits the common "repository object" pattern in TypeScript (export const fooRepo = { findById() {...}, create() {...}, ... }), used instead of a class when there's no instance state.

Root cause

In graphify/extractors/engine.py, the module-level-const branch of _js_extra_walk (handling lexical_declaration with a value type of object/array/as_expression/call_expression/new_expression) creates a single node for the const and then unconditionally returns True. That return short-circuits the caller's default recursive descent into the const's children, so the object literal's own pair/method_definition children — the actual methods — are never visited by any code path.

The already-correct handling just above it, for class fields with function values (class C { handler = () => {} }), walks each member and gives it its own node + a method edge back to the class. This fix mirrors that pattern for the object-literal case.

Fix

Walks the object literal's direct children when the const's value is type == "object". For method_definition children (shorthand methods) and pair children whose value is a function/arrow-function, creates a member node scoped under the const's id, with a method edge from the const. New nodes are wired into callable_def_nids/local_bound_names/function_bodies the same way every other callable node is, so downstream call resolution and the indirect-dispatch guard treat them consistently with any other method.

Testing

• New file tests/test_js_object_literal_repository_methods.py, 7 tests: shorthand + async shorthand + arrow-valued members all get nodes, the container still gets its own node, a method edge exists from container to each member, an in-body call resolves to a free-standing helper, and a same-file external call to repo.findX() resolves to the member node. (Cross-file resolution through an imported plain-object binding — as opposed to a new Class() instance, which test_ts_receiver_member_calls.py already covers — is a separate, broader concern out of scope here, matching JS/TS extractor: instance-method calls (this.x.y() / obj.method()) never produce calls/indirect_call edges to the method node #2023/fix: indirect JS/TS call resolution for dispatch tables and callbacks #1985.)
• Full JS/TS-filtered suite: 675 passed.
• Full suite: 3344 passed, 167 skipped. 12 failures, all pre-existing environment-only gaps unrelated to this change (missing optional openai/tree-sitter-hcl deps, a wheel-build toolchain nuance) — none touch JS/TS.
• Verified against a real production 28-method repository object (not included, private codebase) — all 28 methods now correctly appear as nodes with correct line numbers; previously none did.

🤖 Generated with Claude Code