Skip to content

fix(bun:test): constructing a mock whose implementation returns a primitive now yields an object#31362

Closed
robobun wants to merge 1 commit into
mainfrom
farm/4e0236f3/mock-construct-object
Closed

fix(bun:test): constructing a mock whose implementation returns a primitive now yields an object#31362
robobun wants to merge 1 commit into
mainfrom
farm/4e0236f3/mock-construct-object

fix(bun:test): return an object when constructing a mock whose implem…

855241d
Select commit
Loading
Failed to load commit list.
Claude / Claude Code Review completed May 24, 2026 in 11m 39s

Code review found 2 potential issues

Found 3 candidates, confirmed 2. See review comments for details.

Details

Severity Count
🔴 Important 0
🟡 Nit 1
🟣 Pre-existing 0
Severity File:Line Issue
🟡 Nit src/jsc/bindings/JSMockFunction.cpp:988-1011 Construct path: this-binding and mock.instances still diverge from Jest

Annotations

Check warning on line 1011 in src/jsc/bindings/JSMockFunction.cpp

See this annotation in the file changed.

@claude claude / Claude Code Review

Construct path: this-binding and mock.instances still diverge from Jest

This fixes the crash, but the comment claiming "ordinary `[[Construct]]` semantics" overstates what the code does: ordinary `[[Construct]]` allocates the receiver from `newTarget.prototype` *before* the body runs and binds it as `this`, whereas here the implementation runs first (via `jsMockFunctionCall`, with `callframe->thisValue()`) and the fresh object is created only afterward. So `const fn = jest.fn(function () { this.value = 42 }); new fn()` returns an empty object in Bun but `{value: 42}