refactor(extractor): align typeMapWalk currentClass reset with returnTypeMapWalk

[carlos-alm]

Summary

• `extractObjectRestParamBindingsWalk.walk` now explicitly returns early with `null` `currentClass` when entering `function_declaration`, `generator_function_declaration`, and `method_definition` bodies
• This mirrors the established pattern in `extractReturnTypeMapWalk` (lines ~1431–1446)
• Adds a comment explaining why `class_declaration`/`class_body` nodes do propagate the class name (constructor/method assignments must be keyed as `ClassName.prop`)
• `buildCallEdges` same-file fallback lookup is narrowed to `kind === 'function' || kind === 'method'` to prevent spurious call edges to variables or class nodes that happen to share a name with a called function; arrow functions and function expressions are stored as kind `'function'` so they are not affected

Behavior of `extractObjectRestParamBindingsWalk` unchanged — the previous code already passed `null` implicitly (the `childClass` variable defaulted to `null` for all non-class nodes). The fix makes the intent explicit to prevent future extensions from silently inheriting wrong class context.

Test plan

• `npx vitest run tests/parsers/javascript.test.ts` — all previously passing tests still pass
• `npx vitest run tests/integration/` — all previously passing tests still pass

Closes #1386

[greptile-apps]

Greptile Summary

This PR makes two targeted fixes to the JavaScript extractor and call-edge builder: it explicitly early-returns with null class context when recursing into function_declaration/generator_function_declaration/method_definition bodies in extractObjectRestParamBindingsWalk (mirroring extractReturnTypeMapWalk), and narrows the same-file fallback lookup in buildCallEdges to kind === 'function' || kind === 'method' to prevent spurious edges to same-named variables or class nodes. It also rolls back @vitest sub-packages from 4.1.8 to 4.1.7 in package-lock.json.

• extractObjectRestParamBindingsWalk: behavior is functionally unchanged (the previous code defaulted childClass to null for these node types anyway), but the explicit early return makes the intent clear and prevents future extensions from silently inheriting wrong class context.
• buildCallEdges: the definePropertyReceivers fallback path now filters out non-callable nodes (variables, class declarations) that happen to share a name with the called function in the same file.

Confidence Score: 5/5

Safe to merge — both changes are conservative narrowings that either make existing implicit behaviour explicit or restrict a fallback lookup to callable nodes only.

The extractObjectRestParamBindingsWalk change is purely cosmetic (the previous default already produced null for these node types). The buildCallEdges narrowing removes only spurious edges that were never intentional. The package-lock rollback is a minor version change with no code impact.

No files require special attention.

Important Files Changed

Filename	Overview
src/extractors/javascript.ts	Adds explicit early-return with null class context for function/method node types in extractObjectRestParamBindingsWalk; behavior is preserved, intent is clearer and future-proofed.
src/domain/graph/builder/incremental.ts	Narrows same-file fallback in buildCallEdges to kind === 'function'
package-lock.json	Rolls back @vitest/coverage-v8, @vitest/pretty-format, and @vitest/utils from 4.1.8 to 4.1.7; a minor version rollback with no apparent corresponding change to package.json.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A[extractObjectRestParamBindingsWalk\nwalk node] --> B{node type?}
    B -->|function_declaration\ngenerator_function_declaration\nmethod_definition| C[Extract fnName & paramsNode\nRegister rest-param bindings]
    C --> D[Recurse children\nwith currentClass = null]
    D --> E[return]
    B -->|class_declaration / class| F[childClass = class name]
    F --> G[Recurse children\nwith childClass]
    B -->|class_body| H[childClass = currentClass]
    H --> G
    B -->|other| I[childClass = null]
    I --> G

    subgraph buildCallEdges [buildCallEdges — definePropertyReceivers fallback]
        J[No targets from qualified lookup] --> K[sameFile = byNameAndFile\ncall.name, relPath]
        K --> L[.filter kind === 'function'\nor kind === 'method']
        L --> M{matches?}
        M -->|yes| N[targets = sameFile]
        M -->|no| O[no edge added]
    end

Loading

_{Reviews (10): Last reviewed commit: "Merge branch 'main' into refactor/align-..." | Re-trigger Greptile}

[github-actions]

Codegraph Impact Analysis

3 functions changed → 21 callers affected across 3 files

• buildCallEdges in src/domain/graph/builder/incremental.ts:485 (5 transitive callers)
• extractObjectRestParamBindingsWalk in src/extractors/javascript.ts:2516 (3 transitive callers)
• walk in src/extractors/javascript.ts:2520 (26 transitive callers)

[carlos-alm]

@greptileai

[carlos-alm]

Two additional commits pushed to fix regressions introduced during earlier merge conflict resolution:

1. Restored case 'class': in walkJavaScriptNode — this was lost when resolving merge conflicts in 6e72569, breaking class expression extends-relationship extraction (e.g. const Foo = class Child extends Parent { ... } no longer recorded in ctx.classes).

2. Changed handleStaticBlock to emit kind: 'method' instead of kind: 'function' — static blocks are logically method-scoped (they run in class initialization context), and CHA dispatch requires a method-kind node to walk up the parent class for super.method() resolution.

Also updated the 'extracts static blocks as function definitions' test to expect kind: 'method', consistent with the behavior change. All 113 JS parser tests and all CI checks now pass.

@greptileai

[carlos-alm]

Greptile's concern about the unfiltered same-file fallback in the definePropertyReceivers block has been addressed. The byNameAndFile(call.name, relPath) lookup now filters to kind === 'function' || kind === 'method' to avoid matching unrelated variables or class nodes that happen to share the same name in the file.

The filter accepts both 'function' and 'method' (not just 'method') because the primary use case for this fallback is resolving free function targets — the fixture in issue #1292 (handlers.auth = authMiddleware, where authMiddleware is a top-level function) confirms this. Restricting to 'method' only would break that case.

Merge conflict resolution also pushed (the duplicate blocks created by git's auto-merge of the identical fallback sections have been removed).

[carlos-alm]

@greptileai

[carlos-alm]

PR description updated to fix incorrect function name reference: the changed function is extractObjectRestParamBindingsWalk.walk, not extractTypeMapWalk.walk. Also added documentation of the buildCallEdges same-file fallback filter (the behavioral change that was previously unmentioned in the PR summary).