fix(bun:test): constructing a mock whose implementation returns a primitive now yields an object#31362
Closed
robobun wants to merge 1 commit into
Closed
fix(bun:test): constructing a mock whose implementation returns a primitive now yields an object#31362robobun wants to merge 1 commit into
robobun wants to merge 1 commit into
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
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}
Loading