- 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.
## Summary
Fixes#20053
When a server sends zstd-compressed data with chunked transfer encoding,
each chunk may be compressed as a separate zstd frame. Previously, Bun's
zstd decompressor would stop after the first frame, causing responses to
be truncated at 16KB.
## The Fix
The fix modifies the zstd decompressor (`src/deps/zstd.zig`) to continue
decompression when a frame completes but input data remains. When
`ZSTD_decompressStream` returns 0 (frame complete), we now check if
there's more input data and reinitialize the decompressor to handle the
next frame.
## Testing
Added regression tests in `test/regression/issue/20053.test.ts` that:
1. Test multi-frame zstd decompression where two frames need to be
concatenated
2. Simulate the exact Hono + compression middleware scenario from the
original issue
Both tests fail without the fix (truncating at 16KB) and pass with the
fix.
## Verification
```bash
# Without fix (regular bun):
$ bun test test/regression/issue/20053.test.ts
0 pass
2 fail
# With fix (debug build):
$ bun bd test test/regression/issue/20053.test.ts
2 pass
0 fail
```
🤖 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>
## What does this PR do?
Fixes https://github.com/oven-sh/bun/issues/22650
Fixes https://github.com/oven-sh/bun/issues/22615
Fixes https://github.com/oven-sh/bun/issues/22603
Fixes https://github.com/oven-sh/bun/issues/22602
Fixes a crash that occurred when running shell commands through `bun
run` (package.json scripts) on Windows that use the `&&` operator
followed by an external command.
### The Problem
The minimal reproduction was:
```bash
bun exec 'echo && node --version'
```
This would crash with: `panic(main thread): attempt to use null value`
### Root Causes
Two issues were causing the crash:
1. **Missing top_level_dir**: When `runPackageScriptForeground` creates
a MiniEventLoop for running package scripts, it wasn't setting the
`top_level_dir` field. This caused a null pointer dereference when the
shell tried to access it.
2. **MovableIfWindowsFd handling**: After PR #21800 introduced
`MovableIfWindowsFd` to handle file descriptor ownership on Windows, the
`IOWriter.fd` could be moved to libuv, leaving it null. When the shell
tried to spawn an external command after a `&&` operator, it would crash
trying to access this null fd.
### The Fix
1. Set `mini.top_level_dir = cwd` after initializing the MiniEventLoop
in `run_command.zig`
2. In `IO.zig`, when the fd has been moved to libuv (is null), use
`.inherit` for stdio instead of trying to pass the null fd
### How did you verify your code works?
- Added a regression test that reproduces the issue
- Verified the test fails without the fix and passes with it
- Tested the minimal reproduction command directly
- The fix correctly allows both commands in the `&&` chain to execute
```bash
# Before fix: crashes
> bun exec 'echo test && node --version'
panic(main thread): attempt to use null value
# After fix: works correctly
> bun exec 'echo test && node --version'
test
v22.4.1
```
<sub>
also probably fixes#22615 and fixes#22603 and fixes#22602
</sub>
---------
Co-authored-by: Zack Radisic <zack@theradisic.com>
Co-authored-by: autofix-ci[bot] <114827586+autofix-ci[bot]@users.noreply.github.com>
### What does this PR do?
This branch:
> Ran 1600 tests across 46 files. [63.24s]
Main:
> Ran 1600 tests across 46 files. [137.05s]
This makes the bundler tests run about 60 seconds faster
### How did you verify your code works?
## Summary
- Fixes incorrect banner positioning when using `--banner` with
`--format=cjs` and `--target=bun`
- Ensures Bun-specific comments (`// @bun @bun-cjs`) appear before user
banner content
- Properly extracts and positions hashbangs from banner content
## Problem
When using `--banner` with `--format=cjs --target=bun`, the banner was
incorrectly placed before the `// @bun @bun-cjs` comment and CJS wrapper
function, breaking the module format that Bun expects.
## Solution
Implemented proper ordering:
1. **Hashbang** (from source file or extracted from banner if it starts
with `#!`)
2. **@bun comments** (e.g., `// @bun`, `// @bun @bun-cjs`, `// @bun
@bytecode`)
3. **CJS wrapper** `(function(exports, require, module, __filename,
__dirname) {`
4. **Banner content** (excluding any extracted hashbang)
## Test plan
- [x] Added comprehensive tests for banner positioning with CJS/ESM and
Bun target
- [x] Tests cover hashbang extraction from banners
- [x] Tests verify proper ordering with bytecode generation
- [x] All existing tests pass
🤖 Generated with [Claude Code](https://claude.ai/code)
---------
Co-authored-by: Claude <noreply@anthropic.com>
### What does this PR do?
### How did you verify your code works?
---------
Co-authored-by: Jarred Sumner <jarred@jarredsumner.com>
Co-authored-by: autofix-ci[bot] <114827586+autofix-ci[bot]@users.noreply.github.com>
## Summary
- Fixes ENXIO error when reopening `/dev/tty` after stdin reaches EOF
- Fixes ESPIPE error when reading from reopened TTY streams
- Adds ref/unref methods to tty.ReadStream for socket-like behavior
- Enables TUI applications that read piped input then switch to
interactive TTY mode
## The Problem
TUI applications and interactive CLI tools have a pattern where they:
1. Read piped input as initial data: `echo "data" | tui-app`
2. After stdin ends, reopen `/dev/tty` for interactive session
3. Use the TTY for interactive input/output
This didn't work in Bun due to missing functionality:
- **ESPIPE error**: TTY ReadStreams incorrectly had `pos=0` causing
`pread()` syscall usage which fails on character devices
- **Missing methods**: tty.ReadStream lacked ref/unref methods that TUI
apps expect for socket-like behavior
- **Hardcoded isTTY**: tty.ReadStream always set `isTTY = true` even for
non-TTY file descriptors
## The Solution
1. **Fix ReadStream position**: For fd-based streams (like TTY), don't
default `start` to 0. This keeps `pos` undefined, ensuring `read()`
syscall is used instead of `pread()`.
2. **Add ref/unref methods**: Implement ref/unref on tty.ReadStream
prototype to match Node.js socket-like behavior, allowing TUI apps to
control event loop behavior.
3. **Dynamic isTTY check**: Use `isatty(fd)` to properly detect if the
file descriptor is actually a TTY.
## Test Results
```bash
$ bun test test/regression/issue/tty-reopen-after-stdin-eof.test.ts
✓ can reopen /dev/tty after stdin EOF for interactive session
✓ TTY ReadStream should not set position for character devices
$ bun test test/regression/issue/tty-readstream-ref-unref.test.ts
✓ tty.ReadStream should have ref/unref methods when opened on /dev/tty
✓ tty.ReadStream ref/unref should behave like Node.js
$ bun test test/regression/issue/tui-app-tty-pattern.test.ts
✓ TUI app pattern: read piped stdin then reopen /dev/tty
✓ tty.ReadStream handles non-TTY file descriptors correctly
```
## Compatibility
Tested against Node.js v24.3.0 - our behavior now matches:
- ✅ Can reopen `/dev/tty` after stdin EOF
- ✅ TTY ReadStream has `pos: undefined` and `start: undefined`
- ✅ tty.ReadStream has ref/unref methods for socket-like behavior
- ✅ `isTTY` is properly determined using `isatty(fd)`
---------
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?
- Change Header struct start fields to default to 1 instead of 0
- Rename Header.zeroes to Header.empty with proper initialization
- Maintain @max(1, ...) validation in parsing to ensure one-based
indexing
- Preserve compatibility with existing patch file formats
🤖 Generated with [Claude Code](https://claude.ai/code)
### How did you verify your code works?
Co-authored-by: Claude Bot <claude-bot@bun.sh>
Co-authored-by: Claude <noreply@anthropic.com>
Co-authored-by: Zack Radisic <56137411+zackradisic@users.noreply.github.com>
## Summary
- Fixes#22596 where Nuxt crashes when building with rolldown-vite
- Aligns Bun's NAPI GC safety checks with Node.js behavior by only
enforcing them for experimental NAPI modules
## The Problem
Bun was incorrectly enforcing GC safety checks
(`NAPI_CHECK_ENV_NOT_IN_GC`) for ALL NAPI modules, regardless of
version. This caused crashes when regular production NAPI modules called
`napi_reference_unref` from finalizers, which is a common pattern in the
ecosystem (e.g., rolldown-vite).
The crash manifested as:
```
panic: Aborted
- napi.h:306: napi_reference_unref
```
## Root Cause: What We Did Wrong
Our previous implementation always enforced the GC check for all NAPI
modules:
**Before (incorrect):**
```cpp
// src/bun.js/bindings/napi.h:304-311
void checkGC() const
{
NAPI_RELEASE_ASSERT(!inGC(),
"Attempted to call a non-GC-safe function inside a NAPI finalizer...");
// This was called for ALL modules, not just experimental ones
}
```
This was overly restrictive and didn't match Node.js's behavior, causing
legitimate use cases to crash.
## The Correct Solution: How Node.js Does It
After investigating Node.js source code, we found that Node.js **only
enforces GC safety checks for experimental NAPI modules**. Regular
production modules are allowed to call functions like
`napi_reference_unref` from finalizers for backward compatibility.
### Evidence from Node.js Source Code
**1. The CheckGCAccess implementation**
(`vendor/node/src/js_native_api_v8.h:132-143`):
```cpp
void CheckGCAccess() {
if (module_api_version == NAPI_VERSION_EXPERIMENTAL && in_gc_finalizer) {
// Only fails if BOTH conditions are true:
// 1. Module is experimental (version 2147483647)
// 2. Currently in GC finalizer
v8impl::OnFatalError(...);
}
}
```
**2. NAPI_VERSION_EXPERIMENTAL definition**
(`vendor/node/src/js_native_api.h:9`):
```cpp
#define NAPI_VERSION_EXPERIMENTAL 2147483647 // INT_MAX
```
**3. How it's used in napi_reference_unref**
(`vendor/node/src/js_native_api_v8.cc:2814-2819`):
```cpp
napi_status NAPI_CDECL napi_reference_unref(napi_env env,
napi_ref ref,
uint32_t* result) {
CHECK_ENV_NOT_IN_GC(env); // This check only fails for experimental modules
// ... rest of implementation
}
```
## Our Fix: Match Node.js Behavior Exactly
**After (correct):**
```cpp
// src/bun.js/bindings/napi.h:304-315
void checkGC() const
{
// Only enforce GC checks for experimental NAPI versions, matching Node.js behavior
// See: https://github.com/nodejs/node/blob/main/src/js_native_api_v8.h#L132-L143
if (m_napiModule.nm_version == NAPI_VERSION_EXPERIMENTAL) {
NAPI_RELEASE_ASSERT(!inGC(), ...);
}
// Regular modules (version <= 8) can call napi_reference_unref from finalizers
}
```
This change means:
- **Regular NAPI modules** (version 8 and below): ✅ Can call
`napi_reference_unref` from finalizers
- **Experimental NAPI modules** (version 2147483647): ❌ Cannot call
`napi_reference_unref` from finalizers
## Why This Matters
Many existing NAPI modules in the ecosystem were written before the
stricter GC rules and rely on being able to call functions like
`napi_reference_unref` from finalizers. Node.js maintains backward
compatibility by only enforcing the stricter rules for modules that
explicitly opt into experimental features.
By not matching this behavior, Bun was breaking existing packages that
work fine in Node.js.
## Test Plan
Added comprehensive tests that verify both scenarios:
### 1. test_reference_unref_in_finalizer.c (Regular Module)
- Uses default NAPI version (8)
- Creates 100 objects with finalizers that call `napi_reference_unref`
- **Expected:** Works without crashing
- **Result:** ✅ Passes with both Node.js and Bun (with fix)
### 2. test_reference_unref_in_finalizer_experimental.c (Experimental
Module)
- Uses `NAPI_VERSION_EXPERIMENTAL` (2147483647)
- Creates objects with finalizers that call `napi_reference_unref`
- **Expected:** Crashes with GC safety assertion
- **Result:** ✅ Correctly fails with both Node.js and Bun (with fix)
## Verification
The tests prove our fix is correct:
```bash
# Regular module - should work
$ bun-debug --expose-gc main.js test_reference_unref_in_finalizer '[]'
✅ SUCCESS: napi_reference_unref worked in finalizers without crashing
# Experimental module - should fail
$ bun-debug --expose-gc main.js test_reference_unref_in_finalizer_experimental '[]'
✅ ASSERTION FAILED: Attempted to call a non-GC-safe function inside a NAPI finalizer
```
Both behaviors now match Node.js exactly.
## Impact
This fix:
1. Resolves crashes with rolldown-vite and similar packages
2. Maintains backward compatibility with the Node.js ecosystem
3. Still enforces safety for experimental NAPI features
4. Aligns Bun's behavior with Node.js's intentional design decisions
🤖 Generated with Claude Code
Co-Authored-By: Claude <noreply@anthropic.com>
---------
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>
Co-authored-by: Zack Radisic <zack@theradisic.com>
This update adds detailed logging to the DevServer's initialization process, including framework configuration details such as server components, React Fast Refresh, and file system router types. Additionally, it logs the directory being scanned for routes and the number of routes found, improving visibility into the server's setup and routing process.
This update allows users to specify the `--app` flag when running Bun commands. If the flag is provided without additional arguments, the CLI will automatically look for and execute the bun.app.ts or bun.app.js file in the current working directory. If the file is not found, an error message will be displayed, guiding users to the expected file locations.
