[master] Michijs Dependabot changes #223

ghost · 2025-10-13T01:07:10Z

Updated Packages

Bump bun-types from 1.2.20 to 1.3.0

ghost · 2025-10-13T01:07:11Z

Bump bun-types from 1.2.20 to 1.3.0

Changelog:

Sourced from releases.
        ### bun-v1.3.0
Read the blog post

Windows:
powershell -c "irm bun.sh/install.ps1|iex"
To upgrade to Bun v1.3:
bun upgrade

Commit history:

db7bcd Refactor: move ZigException functions to dedicated file (#23560)
Summary

This PR moves error-related functions from bindings.cpp into a new
dedicated file ZigException.cpp for better code organization.

Changes

Moved the following functions to ZigException.cpp:
- populateStackFrameMetadata
- populateStackFramePosition
- populateStackFrame
- populateStackTrace
- fromErrorInstance
- exceptionFromString
- JSC__JSValue__toZigException
- ZigException__collectSourceLines
- JSC__Exception__getStackTrace
Also moved helper functions and types:
- V8StackTraceIterator class
- getNonObservable
- PopulateStackTraceFlags enum
- StringView_slice helper
- SYNTAX_ERROR_CODE macro
Test plan
- Built successfully with bun bd
- All exception handling functions are properly exported
- No functional changes, pure refactoring
🤖 Generated with Claude Code

Co-authored-by: Claude Bot <claude-bot@bun.sh>
Co-authored-by: Claude <noreply@anthropic.com>
caa4f5 refactor: move ReadableStream-related functions from ZigGlobalObject.cpp to ReadableStream.cpp (#23547)

Summary

This PR moves all ReadableStream-related functions from
ZigGlobalObject.cpp to ReadableStream.cpp for better code
organization and maintainability.

Changes

Moved 17 functions from ZigGlobalObject.cpp to ReadableStream.cpp:

Core ReadableStream Functions
- ReadableStream__tee - with invokeReadableStreamFunction helper
  (converted to lambda)
- ReadableStream__cancel
- ReadableStream__detach
- ReadableStream__isDisturbed
- ReadableStream__isLocked
- ReadableStreamTag__tagged
Stream Creation & Conversion
- ZigGlobalObject__createNativeReadableStream
- ZigGlobalObject__readableStreamToArrayBufferBody
- ZigGlobalObject__readableStreamToArrayBuffer
- ZigGlobalObject__readableStreamToBytes
- ZigGlobalObject__readableStreamToText
- ZigGlobalObject__readableStreamToFormData
- ZigGlobalObject__readableStreamToJSON
- ZigGlobalObject__readableStreamToBlob
Host Functions
- functionReadableStreamToArrayBuffer
- functionReadableStreamToBytes
Technical Details

File Changes
- ReadableStream.cpp: Added necessary includes and all
  ReadableStream functions
- ReadableStream.h: Added forward declarations for code generator
  functions
- ZigGlobalObject.cpp: Removed moved functions (394 lines removed)
Implementation Notes
- Added proper namespace declarations (using namespace JSC; using namespace WebCore;) to all extern "C" functions
- Used correct namespace qualifiers for types (e.g., Bun::IDLRawAny,
  Bun::AbortError)
- Added required includes: WebCoreJSBuiltins.h, ZigGlobalObject.h,
  ZigGeneratedClasses.h, helpers.h, BunClientData.h,
  BunIDLConvert.h
Testing
- ✅ Builds successfully with debug configuration
- ✅ All functions maintain identical behavior
- ✅ No API changes
Benefits
1. Better code organization: ReadableStream functionality is now
  consolidated in one place
2. Improved maintainability: Easier to find and modify
  ReadableStream-related code
3. Reduced file size: ZigGlobalObject.cpp is now ~400 lines
  smaller
🤖 Generated with Claude Code

Co-authored-by: Claude Bot <claude-bot@bun.sh>
5196be Spend less time linking in debug builds
f00e18 Fix crash handler not dumping stack traces on Linux aarch64 (#23549)

What does this PR do?

Fixes the crash handler failing to capture and display stack traces on
Linux ARM64 systems.

Before:
```
============================================================
panic(main thread): cast causes pointer to be null
```
No stack trace shown.

After:
```
============================================================
panic(main thread): cast causes pointer to be null
bun.js.api.FFIObject.Reader.u8
/workspace/bun/src/bun.js/api/FFIObject.zig:67:41

bun.js.jsc.host_fn.toJSHostCall__anon_2545765
/workspace/bun/src/bun.js/jsc/host_fn.zig:93:5
```
Full stack trace with source locations.

Root Cause
- Zig's std.debug.captureStackTrace uses StackIterator.init() which
  falls back to frame pointer-based unwinding when no context is provided
- Frame pointer-based unwinding doesn't work reliably on ARM64, even
  with -fno-omit-frame-pointer enabled
- This resulted in 0 frames being captured (trace.index == 0)
Changes
1. Use glibc's backtrace() on Linux: On Linux with glibc (not musl),
  always use glibc's backtrace() function instead of Zig's
  StackIterator. glibc's implementation properly uses DWARF unwinding
  information from .eh_frame sections.
2. Skip crash handler frames: After capturing with backtrace(),
  find the desired begin_addr in the trace (within 128 byte tolerance)
  and filter out crash handler internal frames for cleaner output. If
  begin_addr is not found, use the complete backtrace.
3. Preserve existing behavior:
  - Non-debug builds: Use WTF printer (fast, no external deps)
- Debug builds: Fall through to llvm-symbolizer (detailed source info)
How did you verify your code works?

Reproduced the crash:
```
bun-debug --print 'Bun.FFI.read.u8(0)'
```
Verified that:
- ✅ Stack traces now appear on Linux ARM64 with proper source locations
- ✅ Crash handler frames are properly filtered out
- ✅ llvm-symbolizer integration works for debug builds
- ✅ WTF printer is used for release builds
- ✅ When begin_addr is not found, complete backtrace is used
🤖 Generated with Claude Code

Co-authored-by: Claude Bot <claude-bot@bun.sh>
Co-authored-by: Claude <noreply@anthropic.com>
356d0e fix: use std::call_once for thread-safe JSC initialization (#23542)

What does this PR do?

Fixes a race condition where multiple threads could attempt to
initialize JavaScriptCore concurrently when the bundler's thread pool
processes files with macros.

Fixes #23540

How did you verify your code works?

Reproduced the segfault with the Brisa project build and verified the
fix resolves it:
```
git clone https://redirect.github.com/brisa-build/brisa
cd brisa
bun install
bun run build
```
Before the fix: Segmentation fault with assertion failure
After the fix: Build proceeds without crashing

Root Cause

The previous implementation used a simple boolean flag has_loaded_jsc
without synchronization. When multiple bundler threads tried to execute
macros simultaneously, they could race through the initialization check
before JSC::initialize() finished finalizing options on another
thread.

This caused crashes with:
```
ASSERTION FAILED: g_jscConfig.options.allowUnfinalizedAccess || g_jscConfig.options.isFinalized
vendor/WebKit/Source/JavaScriptCore/runtime/Options.h(146) : static OptionsStorage::Bool &JSC::Options::forceTrapAwareStackChecks()
```
The Fix

Replace the boolean flag with std::call_once, which provides:
- Thread-safe initialization
- Guaranteed exactly-once execution
- Proper memory barriers to ensure visibility across threads
The initialization code is now wrapped in a lambda passed to
std::call_once, capturing the necessary parameters (evalMode,
envp, envc, onCrash).

🤖 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.redirect.github.com>
b8b9d7 Emit eh-frame-hdr when not using LTO
755b41 Add BUN_WATCHER_TRACE environment variable for debugging file watcher events (#23533)

Summary

Adds BUN_WATCHER_TRACE environment variable that logs all file watcher
events to a JSON file for debugging. When set, the watcher appends
detailed event information to the specified file path.

Motivation

Debugging watch-related issues (especially with bun --watch and bun --hot) can be difficult without visibility into what the watcher is
actually seeing. This feature provides detailed trace logs showing
exactly which files are being watched and what events are triggered.

Implementation
- Isolated module (src/watcher/WatcherTrace.zig) - All trace logic
  in separate file
- No locking needed - Watcher runs on its own thread, no mutex
  required
- Append-only mode - Traces persist across multiple runs for easier
  debugging
- Silent errors - Won't break functionality if trace file can't be
  created
- JSON format - Easy to parse and analyze
Usage
```
BUN_WATCHER_TRACE=/tmp/watch.log bun --watch script.js
BUN_WATCHER_TRACE=/tmp/hot.log bun --hot server.ts
```
JSON Output Format

Each line is a JSON object with:
```
{
  "timestamp": 1760280923269,
  "index": 0,
  "path": "/path/to/watched/file.js",
  "delete": false,
  "write": true,
  "rename": false,
  "metadata": false,
  "move_to": false,
  "changed_files": ["script.js"]
}
```
Testing

All tests use stdout streaming to wait for actual reloads (no
sleeps/timeouts):
- Tests with --watch flag
- Tests with fs.watch API
- Tests that trace file appends across multiple runs
- Tests validation of JSON format and event details
```
✅ 4 pass
❌ 0 fail
📊 52 expect() calls
```
Files Changed
- src/Watcher.zig - Minimal integration with WatcherTrace module
- src/watcher/WatcherTrace.zig - New isolated trace implementation
- src/watcher/KEventWatcher.zig - Calls writeTraceEvents before
  onFileUpdate
- src/watcher/INotifyWatcher.zig - Calls writeTraceEvents before
  onFileUpdate
- src/watcher/WindowsWatcher.zig - Calls writeTraceEvents before
  onFileUpdate
- test/cli/watch/watcher-trace.test.ts - Comprehensive tests
🤖 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.redirect.github.com>
d29aa5 deps: update elysia to 1.4.11 (#23518)

What does this PR do?

Updates elysia to version 1.4.11

Compare: https://redirect.github.com/elysiajs/elysia/compare/1.4.10...1.4.11

Auto-updated by this
workflow

Co-authored-by: Jarred-Sumner <709451+Jarred-Sumner@users.noreply.redirect.github.com>
40da08 fix(shell): handle UV_ENOTCONN gracefully in shell subprocess (#23520)
5bdc32 Add support for localAddress and localPort in TCP connections (#23464)

Summary

This PR implements support for localAddress and localPort options in
TCP connections, allowing users to bind outgoing connections to a
specific local IP address and port.

This addresses issue #6888 and implements Node.js-compatible behavior
for these options.

Changes

C Layer (uSockets)
- bsd.c: Modified bsd_create_connect_socket() to accept a
  local_addr parameter and call bind() before connect() when a local
  address is specified
- context.c: Updated us_socket_context_connect() and
  start_connections() to parse and pass local address parameters through
  the connection flow
- libusockets.h: Updated public API signatures to include
  local_host and local_port parameters
- internal.h: Added local_host and local_port fields to
  us_connecting_socket_t structure
- openssl.c: Updated SSL connection function to match the new
  signature
Zig Layer
- SocketContext.zig: Updated connect() method to accept and pass
  through local_host and local_port parameters
- socket.zig: Modified connectAnon() to handle local address
  binding, including IPv6 bracket removal and proper memory management
- Handlers.zig: Added localAddress and localPort fields to
  SocketConfig and implemented parsing from JavaScript options
- Listener.zig: Updated connection structures to store and pass
  local binding information
- socket.zig (bun.js/api/bun): Modified doConnect() to extract
  and pass local address options
- Updated all other call sites (HTTP, MySQL, PostgreSQL, Valkey) to pass
  null, 0 for backward compatibility
JavaScript Layer
- net.ts: Enabled localAddress and localPort support by
  passing these options to doConnect() and removing TODO comments
Tests
- 06888-localaddress.test.ts: Added comprehensive tests covering:
  - IPv4 local address binding
  - IPv4 local address and port binding
  - IPv6 local address binding (loopback)
  - Backward compatibility (connections without local address)
Test Results

All tests pass successfully:
```
✓ TCP socket can bind to localAddress - IPv4
✓ TCP socket can bind to localAddress and localPort - IPv4
✓ TCP socket can bind to localAddress - IPv6 loopback
✓ TCP socket without localAddress works normally

4 pass, 0 fail
```
API Usage
```
import net from "net";

// Connect with a specific local address
const client = net.createConnection({
  host: "example.com",
  port: 80,
  localAddress: "192.168.1.100",  // Bind to this local IP
  localPort: 0,                    // Let system assign port (optional)
});
```
Implementation Details

The implementation follows the same flow as Node.js:
1. JavaScript options are parsed in Handlers.zig
2. Local address/port are stored in the connection configuration
3. The Zig layer processes and passes them to the C layer
4. The C layer parses the local address and calls bind() before
  connect()
5. Both IPv4 and IPv6 addresses are supported
Memory management is handled properly throughout the stack, with
appropriate allocation/deallocation at each layer.

Closes #6888

🤖 Generated with Claude Code

Co-authored-by: Claude Bot <claude-bot@bun.sh>
Co-authored-by: Claude <noreply@anthropic.com>
01924e fix(YAML.stringify): check for more indicators at the beginning of strings (#23516)

What does this PR do?

Makes sure strings are doubled quoted when they start with flow
indicators and :.

Fixes #23502

How did you verify your code works?

Added tests for each indicator in flow and block context
d963a0 Reduce # of redundant resolver syscalls Bump lint-staged from 13.1.0 to 13.1.1 #2 (#23506)

What does this PR do?

How did you verify your code works?

Co-authored-by: Claude Bot <claude-bot@bun.sh>
Co-authored-by: Claude <noreply@anthropic.com>
8ccd17 Make sourcemap generation faster (#23514)

What does this PR do?

How did you verify your code works?
1c84f8 chore: update Claude Code Action to stable version (#23515)
What does this PR do?

Updates the workflow to use the stable Anthropic Claude action.

How did you verify your code works?
0e2961 Add missing error handling for directory entries errors (#23511)
What does this PR do?

Add missing error handling for directory entries errors

The code was missing a check for .err

How did you verify your code works?

Co-authored-by: autofix-ci[bot] <114827586+autofix-ci[bot]@users.noreply.redirect.github.com>
f0807e Update CLAUDE.md
c766c1 Reduce # of redundant system calls in module resolver (#23505)

What does this PR do?

How did you verify your code works?
525315 fix: include cookies in WebSocket upgrade response (#23499)
Fixes #23474

Summary

When request.cookies.set() is called before server.upgrade(), the
cookies are now properly included in the WebSocket upgrade response
headers.

Problem

Previously, cookies set on the request via req.cookies.set() were only
written for regular HTTP responses but were ignored during WebSocket
upgrades. Users had to manually pass cookies via the headers option:
```
server.upgrade(req, {
  headers: {
    "Set-Cookie": `SessionId=${sessionId}`,
  },
});
```
Solution

Modified src/bun.js/api/server.zig to check for and write cookies to
the WebSocket upgrade response after the "101 Switching Protocols"
status is set but before the actual upgrade is performed.

The fix handles both cases:
- When upgrade() is called without custom headers
- When upgrade() is called with custom headers
Testing

Added comprehensive regression tests in
test/regression/issue/23474.test.ts that:
- Verify cookies are set in the upgrade response without custom headers
- Verify cookies are set in the upgrade response with custom headers
- Use Promise.withResolvers() for efficient async handling (no
  arbitrary timeouts)
Tests confirmed:
- ❌ Fail with system bun v1.2.23 (without fix)
- ✅ Pass with debug build v1.3.0 (with fix)
Manual verification
```
curl -i -H "Connection: Upgrade" -H "Upgrade: websocket" \
  -H "Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==" \
  -H "Sec-WebSocket-Version: 13" \
  http://localhost:3000/ws
```
Response now includes:
```
HTTP/1.1 101 Switching Protocols
Set-Cookie: test=123; Path=/; SameSite=Lax
Upgrade: websocket
Connection: Upgrade
...
```
Co-authored-by: Claude Bot <claude-bot@bun.sh>
Co-authored-by: Claude <noreply@anthropic.com>
85a2eb fix #23470 (#23471)

What does this PR do?

CompileResult error message memory was not managed correctly.

Fixes #23470

How did you verify your code works?

Manually
f673ed fix: fix broken scripts in the React templates after the index.ts rename (#23472)
a67ac0 fix: rename index.tsx in React project templates to index.ts (#23469)
622d36 Bump
b0a6fe Update no-validate-leaksan.txt
012a2b Fix Clang 19 detection in Nix flake by setting CMAKE compiler variables (#23445)

Summary

Fixes Clang 19 detection in the Nix flake environment by explicitly
setting CMAKE compiler environment variables in the shellHook.

Problem

When using nix develop or nix print-dev-env, CMake was unable to
detect the Clang 19 compiler because the CMAKE_C_COMPILER and
CMAKE_CXX_COMPILER environment variables were not being set, even
though the compiler was available in the environment.

The shell.nix file correctly sets these variables (lines 80-87), but
flake.nix was missing them.

Solution

Updated flake.nix shellHook to export the same compiler environment
variables as shell.nix:
- CC, CXX, AR, RANLIB
- CMAKE_C_COMPILER, CMAKE_CXX_COMPILER, CMAKE_AR, CMAKE_RANLIB
This ensures consistent compiler detection across both Nix entry points
(nix develop with flakes and nix-shell with shell.nix).

Testing

Verified that all compiler variables are now properly set:
```
nix develop --accept-flake-config --impure --command bash -c 'echo "CMAKE_C_COMPILER=$CMAKE_C_COMPILER"'
# Output: CMAKE_C_COMPILER=/nix/store/.../clang-wrapper-19.1.7/bin/clang
```
Also tested with the profile workflow:
```
nix develop --accept-flake-config --impure --profile ./dev-profile --command true
eval "$(nix print-dev-env ./dev-profile --accept-flake-config --impure)"
echo "CMAKE_C_COMPILER=$CMAKE_C_COMPILER"
# Output: CMAKE_C_COMPILER=/nix/store/.../clang
```
🤖 Generated with Claude Code

Co-authored-by: Claude Bot <claude-bot@bun.sh>
Co-authored-by: Claude <noreply@anthropic.com>
8197a5 Fix WriteBarrier initialization to use WriteBarrierEarlyInit (#23435)

Summary

This PR fixes incorrect WriteBarrier initialization patterns throughout
the Bun codebase where .set() or .setEarlyValue() was being called
in the constructor body or in finishCreation(). According to
JavaScriptCore's WriteBarrier.h, WriteBarriers that are initialized
during construction should use the WriteBarrierEarlyInit constructor
in the initializer list to avoid triggering unnecessary write barriers.

Changes

The following classes were updated to properly initialize WriteBarrier
fields:
1. InternalModuleRegistry - Initialize internal fields in
  constructor using setWithoutWriteBarrier() instead of calling .set()
  in finishCreation()
2. AsyncContextFrame - Pass callback and context to constructor and
  use WriteBarrierEarlyInit
3. JSCommonJSModule - Pass id, filename, dirname to constructor and
  use WriteBarrierEarlyInit
4. JSMockImplementation - Pass initial values to constructor and use
  WriteBarrierEarlyInit
5. JSConnectionsList - Pass connection sets to constructor and use
  WriteBarrierEarlyInit
6. JSBunRequest - Pass params to constructor and initialize both
  m_params and m_cookies using WriteBarrierEarlyInit
7. JSNodeHTTPServerSocket - Initialize currentResponseObject using
  WriteBarrierEarlyInit instead of calling setEarlyValue()
Why This Matters

From JavaScriptCore's WriteBarrier.h:
```
enum WriteBarrierEarlyInitTag { WriteBarrierEarlyInit };

// Constructor for early initialization during object construction
WriteBarrier(T* value, WriteBarrierEarlyInitTag)
{
    this->setWithoutWriteBarrier(value);
}
```
Using WriteBarrierEarlyInit during construction:
- Avoids triggering write barriers when they're not needed
- Is the correct pattern for initializing WriteBarriers before the
  object is fully constructed
- Aligns with JavaScriptCore best practices
Testing
- ✅ Full debug build completes successfully
- ✅ Basic functionality tested (CommonJS modules, HTTP requests, Node
  HTTP servers)
- ✅ No regressions observed
Note on generate-classes.ts

The code generator (generate-classes.ts) does not need updates because
generated classes intentionally leave WriteBarrier fields (callbacks,
cached fields, values) uninitialized. They start with
default-constructed WriteBarriers and are populated later by Zig code
via setter functions, which is the correct pattern for those fields.

Co-authored-by: Claude Bot <claude-bot@bun.sh>
Co-authored-by: Claude <noreply@anthropic.com>
c50db1 fix unpaired deref when write_file fails due to nametoolong (#23438)

Fixes test\regression\issue\23316-long-path-spawn.test.ts

The problem was await Bun.write(join(deepPath, "test.js"), `console.log("hello");`); was failing because the name was too long,
but it failed before refConcurrently was called and it called
unrefConcurrently after failing. so then when the subprocess spawned it
didn't ref.

Co-authored-by: Jarred Sumner <jarred@jarredsumner.com>
312a86 fix writing UTF-16 with a trailing unpaired surrogate to process.stdout/stderr (#23444)

What does this PR do?

Fixes bun -p "process.stderr.write('Hello' + String.fromCharCode(0xd800))".

Also fixes potential index out of bounds if there are many invalid
sequences.

This also affects TextEncoder.

How did you verify your code works?

Added tests for edgecases

Co-authored-by: Jarred Sumner <jarred@jarredsumner.com>

8826b4 Fix WTFTimer issues with Atomics.waitAsync (#23442)

Summary

Fixes two critical issues in WTFTimer when Atomics.waitAsync creates
multiple timer instances.

Problems

1. Use-After-Free in `WTFTimer.fire()`

Location: /workspace/bun/src/bun.js/api/Timer/WTFTimer.zig:70-82

pub fn fire(this: *WTFTimer, _: *const bun.timespec, _: *VirtualMachine) EventLoopTimer.Arm {
    this.event_loop_timer.state = .FIRED;
    this.imminent.store(null, .seq_cst);
    this.runWithoutRemoving();  // ← Callback might destroy `this`
    return if (this.repeat)     // ← UAF: accessing freed memory
        .{ .rearm = this.event_loop_timer.next }
    else
        .disarm;
}

When Atomics.waitAsync creates a DispatchTimer with a timeout, the
timer fires and the callback destroys this, but we continue to access
it.

2. Imminent Pointer Corruption

Location: /workspace/bun/src/bun.js/api/Timer/WTFTimer.zig:36-42

pub fn update(this: *WTFTimer, seconds: f64, repeat: bool) void {
    // Multiple WTFTimers unconditionally overwrite the shared imminent pointer
    this.imminent.store(if (seconds == 0) this else null, .seq_cst);
    // ...
}

All WTFTimer instances share the same
vm.eventLoop().imminent_gc_timer atomic pointer. When multiple timers
are created (GC timer + Atomics.waitAsync timers), they stomp on each
other's imminent state.

Solutions

1. UAF Fix

Read this.repeat and this.event_loop_timer.next before calling
runWithoutRemoving():

const should_repeat = this.repeat;
const next_time = this.event_loop_timer.next;
this.runWithoutRemoving();
return if (should_repeat)
    .{ .rearm = next_time }
else
    .disarm;

2. Imminent Pointer Fix

Use compare-and-swap to only set imminent if it's null, and only clear
it if this timer was the one that set it:

if (seconds == 0) {
    _ = this.imminent.cmpxchgStrong(null, this, .seq_cst, .seq_cst);
    return;
} else {
    _ = this.imminent.cmpxchgStrong(this, null, .seq_cst, .seq_cst);
}

Test Plan

Added regression test at
test/regression/issue/atomics-waitasync-wtftimer-uaf.test.ts:

const buffer = new SharedArrayBuffer(16);
const view = new Int32Array(buffer);
Atomics.store(view, 0, 0);

const result = Atomics.waitAsync(view, 0, 0, 10);
setTimeout(() => {
  console.log("hi");
}, 100);

Before: Crashes with UAF under ASAN
After: Runs cleanly

All existing atomics tests pass.

🤖 Generated with Claude Code

Co-authored-by: Claude Bot <claude-bot@bun.sh>
Co-authored-by: Claude <noreply@anthropic.com>
Co-authored-by: Jarred Sumner <jarred@jarredsumner.com>

f65e28 Add Nix flake for development environment (#23406)

Provides a Nix flake as an alternative to scripts/bootstrap.sh for
setting up the Bun development environment.

What's included:
- flake.nix: Full development environment with all dependencies from
  bootstrap.sh
  - LLVM 19, CMake 3.30+, Node.js 24, Rust, Go
  - Build tools: ninja, ccache, pkg-config, make
  - Chromium dependencies for Puppeteer testing
  - gdb for core dump debugging
- shell.nix: Simple wrapper for nix-shell usage
- cmake/CompilerFlags.cmake: Nix compatibility fixes
  - Disable zstd debug compression (Nix's LLVM not built with zstd)
  - Set _FORTIFY_SOURCE=0 for -O0 debug builds
  - Downgrade _FORTIFY_SOURCE warning to not error
Usage:
```
nix-shell
export CMAKE_SYSTEM_PROCESSOR=$(uname -m)
bun bd
```
Verified working:

✅ Successfully compiles Bun debug build
✅ Binary tested: ./build/debug/bun-debug --version → 1.2.24-debug
✅ All dependencies from bootstrap.sh included

Advantages:
- Fully isolated (no sudo required)
- 100% reproducible dependency versions
- Fast setup with binary caching
Co-authored-by: Claude Bot <claude-bot@bun.sh>
Co-authored-by: Claude <noreply@anthropic.com>
a686b9 Update package.json

Michijs Dependabot changes

f90de55

ghost closed this Oct 20, 2025

ghost deleted the michijs-dependabot branch October 20, 2025 01:08

michijs bot mentioned this pull request Dec 22, 2025

[master] Michijs Dependabot changes #233

Merged

This pull request was closed.

Uh oh!

[master] Michijs Dependabot changes #223

[master] Michijs Dependabot changes #223

Uh oh!

Conversation

ghost commented Oct 13, 2025

Updated Packages

Uh oh!

ghost commented Oct 13, 2025

Bump bun-types from 1.2.20 to 1.3.0

Summary

Changes

Test plan

Summary

Changes

Core ReadableStream Functions

Stream Creation & Conversion

Host Functions

Technical Details

File Changes

Implementation Notes

Testing

Benefits

What does this PR do?

Root Cause

Changes

How did you verify your code works?

What does this PR do?

How did you verify your code works?

Root Cause

The Fix

Summary

Motivation

Implementation

Usage

JSON Output Format

Testing

Files Changed

What does this PR do?

Summary

Changes

C Layer (uSockets)

Zig Layer

JavaScript Layer

Tests

Test Results

API Usage

Implementation Details

What does this PR do?

How did you verify your code works?

What does this PR do?

How did you verify your code works?

What does this PR do?

How did you verify your code works?

What does this PR do?

How did you verify your code works?

What does this PR do?

How did you verify your code works?

What does this PR do?

How did you verify your code works?

Summary

Problem

Solution

Testing

Manual verification

What does this PR do?

How did you verify your code works?

Summary

Problem

Solution

Testing

Summary

Changes

Why This Matters

Testing

Note on generate-classes.ts

What does this PR do?

How did you verify your code works?

Summary

Problems

1. Use-After-Free in `WTFTimer.fire()`