- Changed the version of `react-server-dom-bun` from a local link to a specific experimental version in `package.json` and `bun.lock`.
- Updated the import path for `renderToPipeableStream` to use the `.node` variant for compatibility.
- Added `neo-async` as a dependency for `react-server-dom-bun` to ensure proper functionality.
## Summary
Fixes sourcemap offset issues in DevServer HMR mode that were causing
incorrect line number mappings when debugging.
## Problem
When using DevServer with HMR enabled, sourcemap line numbers were
consistently off by one or more lines when shown in Chrome DevTools. In
some cases, they were off when shown in the terminal as well.
## Solution
### 1. Remove magic +2 offset
Removed an arbitrary "+2" that was added to `runtime.line_count` in
SourceMapStore.zig. The comment said "magic fairy in my dreams said it
would align the source maps" - this was causing positions to be
incorrectly offset.
### 2. Fix double-increment bug
ErrorReportRequest.zig was incorrectly adding 1 to line numbers that
were already 1-based from the browser, causing an off-by-one error.
### 3. Improve type safety
Converted all line/column handling to use `bun.Ordinal` type instead of
raw `i32`, ensuring consistent 0-based vs 1-based conversions throughout
the codebase.
## Test plan
- [x] Added comprehensive sourcemap tests for complex error scenarios
- [x] Tested with React applications in dev mode
- [x] Verified line numbers match correctly in browser dev tools
- [x] Existing sourcemap tests continue to pass
🤖 Generated with [Claude Code](https://claude.ai/code)
Co-authored-by: Claude <noreply@anthropic.com>
## Summary
Fixes#22635 - MessagePort communication fails after being transferred
to a Worker thread.
Fixes https://github.com/oven-sh/bun/issues/22636
The issue was that `MessagePort::addEventListener()` only called
`start()` for attribute listeners (like `onmessage = ...`) but not for
regular event listeners added via `addEventListener()` or the Node.js
EventEmitter wrapper (`.on('message', ...)`).
## Changes
- Modified `MessagePort::addEventListener()` to call `start()` for all
message event listeners, not just attribute listeners
- Added regression test for issue #22635
## Test Plan
- [x] Regression test added and passing
- [x] Original reproduction case from issue #22635 now works correctly
- [x] Existing MessagePort tests still pass
🤖 Generated with [Claude Code](https://claude.ai/code)
---------
Co-authored-by: Claude Bot <claude-bot@bun.sh>
Co-authored-by: Claude <noreply@anthropic.com>
Co-authored-by: autofix-ci[bot] <114827586+autofix-ci[bot]@users.noreply.github.com>
Co-authored-by: Jarred Sumner <jarred@jarredsumner.com>
### What does this PR do?
This fix assertion in debug mode, remove flag `has_js_deinited` since
js_value is tagged with finalized and is more reliable
### How did you verify your code works?
run `bun-debug test test/js/bun/http/serve.test.ts`
<img width="514" height="217" alt="Screenshot 2025-09-16 at 14 51 40"
src="https://github.com/user-attachments/assets/6a0e9d9a-eb98-4602-8c62-403a77dfcf76"
/>
Fixes https://github.com/oven-sh/bun/issues/21547
## Summary
- Fixes "Length out of range of buffer" error when using
`crypto.createSign().sign()` with JWK EC keys and `dsaEncoding:
"ieee-p1363"`
- The issue only occurred with the specific combination of JWK format
keys and IEEE P1363 signature encoding
## The Bug
When signing with EC keys in JWK format and requesting IEEE P1363
signature encoding, the code would:
1. Create a DER-encoded signature
2. Convert it to P1363 format (fixed-size raw r||s concatenation)
3. Replace the signature buffer with the P1363 buffer
4. **But incorrectly use the original DER signature length when creating
the final JSUint8Array**
This caused a buffer overflow since P1363 signatures are always 64 bytes
for P-256 curves, while DER signatures vary in length (typically 70-72
bytes).
## The Fix
Track the correct signature length after P1363 conversion and use it
when creating the final JSUint8Array.
## Test Plan
Added comprehensive tests in
`test/js/node/crypto/sign-jwk-ieee-p1363.test.ts` that:
- Verify the original failing case now works
- Test different encoding options (default DER, explicit DER, IEEE
P1363)
- Test with both JWK objects and KeyObject instances
- Verify signature lengths are correct for each format
The tests fail on the current main branch and pass with this fix.
🤖 Generated with [Claude Code](https://claude.ai/code)
---------
Co-authored-by: Claude Bot <claude-bot@bun.sh>
Co-authored-by: Claude <noreply@anthropic.com>
Co-authored-by: autofix-ci[bot] <114827586+autofix-ci[bot]@users.noreply.github.com>
## Summary
Fixes#22199
When a plugin's `onResolve` handler returns `undefined` or `null`, Bun
should continue to the next plugin or use default resolution. However,
the code was crashing with a segmentation fault.
## The Bug
The crash occurred when:
1. A plugin's `onResolve` handler returned `undefined` (especially from
an async function as a fulfilled promise)
2. The code extracted the promise result but didn't check if it was
undefined before expecting it to be an object
3. This caused an improper exception to be thrown, leading to a crash
## The Fix
1. **Main fix**: Added a check for `undefined/null` after extracting the
result from a fulfilled promise, allowing the code to continue to the
next plugin
2. **Promise rejection fix**: Changed rejected promise handling to
return the promise itself instead of throwing an exception (which was
causing hangs)
3. **Exception handling**: Standardized exception throwing throughout
the file to use the proper `throwException` pattern
## Test Plan
Added comprehensive regression tests in
`test/regression/issue/22199.test.ts` that verify:
- ✅ Async function returning `undefined` doesn't crash
- ✅ Async function returning `null` doesn't crash
- ✅ Sync function returning `undefined` doesn't crash
- ✅ Async function throwing an error properly shows the error
All tests:
- **Fail (crash) with release Bun**: Segmentation fault
- **Pass with this fix**: All test cases pass
## Verification
```bash
# Crashes without the fix
bun test test/regression/issue/22199.test.ts
# Passes with the fix
bun bd test test/regression/issue/22199.test.ts
```
🤖 Generated with [Claude Code](https://claude.ai/code)
---------
Co-authored-by: Claude Bot <claude-bot@bun.sh>
Co-authored-by: autofix-ci[bot] <114827586+autofix-ci[bot]@users.noreply.github.com>
### What does this PR do?
Previously, 'bun whoami' showed a reservation message indicating it was
reserved for future use. This change updates the command to execute 'bun
pm whoami' directly, making it consistent with npm's behavior.
Fixes#22614
Changes:
- Route 'bun whoami' to PackageManagerCommand instead of ReservedCommand
- Update PackageManagerCommand.exec to handle direct 'whoami' invocation
### How did you verify your code works?
- Add tests to verify both 'bun whoami' and 'bun pm whoami' work
correctly
---------
Co-authored-by: Claude Bot <claude-bot@bun.sh>
Co-authored-by: autofix-ci[bot] <114827586+autofix-ci[bot]@users.noreply.github.com>
- Updated `HotReloadEvent.zig` to use duplicated strings for extra files to prevent potential memory issues.
- Commented out unused code related to "bun:app" in `bundle_v2.zig` to improve clarity and maintainability.
- Changed module imports from "react-server-dom-bun" to "react-server-dom-webpack" in multiple files.
- Updated dependencies in package.json and bun.lock to use newer versions of React, React DOM, React Refresh, and the new react-server-dom-webpack package.
- Adjusted type definitions in bun-types to reflect changes in import sources.
This update enhances compatibility with the latest React features and improves the overall framework structure.
