- Remove duplicate dictionary loading from init() method (suggested by empty comments)
- Simplify JavaScript dictionary validation to match Node.js approach
- Remove unused compressUsingDict/decompressUsingDict functions from zstd.zig
- Keep @ptrCast calls as they are required for Zig type conversion
All review comments have been addressed while maintaining functionality.
🤖 Generated with [Claude Code](https://claude.ai/code)
Co-Authored-By: Claude <noreply@anthropic.com>
- Change argument count check to require exactly 5 arguments
- Simplify dictionary_value assignment by removing conditional
- Use setDictionary method instead of inline dictionary loading in init
- Keep @ptrCast calls as they're needed for type conversion
- Make JS always pass 5 arguments (undefined when no dictionary)
🤖 Generated with [Claude Code](https://claude.ai/code)
Co-Authored-By: Claude <noreply@anthropic.com>
Implements dictionary support for ZSTD compression and decompression in node:zlib,
matching Node.js API. Dictionaries can significantly improve compression ratios
for data with predictable patterns.
Changes:
- Add compressUsingDict and decompressUsingDict functions to src/deps/zstd.zig
- Update NativeZstd.zig to handle dictionary loading in compression contexts
- Modify Zstd class in zlib.ts to accept dictionary option and pass to native code
- Add test case from Node.js test suite to verify functionality
The implementation uses ZSTD_CCtx_loadDictionary and ZSTD_DCtx_loadDictionary
APIs for streaming compression/decompression with dictionary support.
🤖 Generated with [Claude Code](https://claude.ai/code)
Co-Authored-By: Claude <noreply@anthropic.com>
## Summary
- Implements automated Windows code signing for x64 and x64-baseline
builds
- Integrates DigiCert KeyLocker for secure certificate management
- Adds CI/CD pipeline support for signing during builds
## Changes
- Added `.buildkite/scripts/sign-windows.sh` script for automated
signing
- Updated CMake configurations to support signing workflow
- Modified build scripts to integrate signing step
## Testing
- Script tested locally with manual signing process
- Successfully signed test binaries at:
- `C:\Builds\bun-windows-x64\bun.exe`
- `C:\Builds\bun-windows-x64-baseline\bun.exe`
## References
Uses DigiCert KeyLocker tools for Windows signing
## Next Steps
- Validate Buildkite environment variables in CI
- Test full pipeline in CI environment
---------
Co-authored-by: Jarred Sumner <jarred@bun.sh>
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#20729
### How did you verify your code works?
There is a test
---------
Co-authored-by: autofix-ci[bot] <114827586+autofix-ci[bot]@users.noreply.github.com>
### What does this PR do?
Add MySQL support, Refactor will be in a followup PR
### How did you verify your code works?
A lot of tests
---------
Co-authored-by: autofix-ci[bot] <114827586+autofix-ci[bot]@users.noreply.github.com>
Co-authored-by: cirospaciari <6379399+cirospaciari@users.noreply.github.com>
### What does this PR do?
Fixes#22014
todo:
- [x] not spawn sync
- [x] better comm to subprocess (not stderr)
- [x] tty
- [x] more tests (also include some tests for the actual implementation
of a provider)
- [x] disable autoinstall?
Scanner template: https://github.com/oven-sh/security-scanner-template
<!-- **Please explain what your changes do**, example: -->
<!--
This adds a new flag --bail to bun test. When set, it will stop running
tests after the first failure. This is useful for CI environments where
you want to fail fast.
-->
---
- [x] Documentation or TypeScript types (it's okay to leave the rest
blank in this case)
- [x] Code changes
### How did you verify your code works?
<!-- **For code changes, please include automated tests**. Feel free to
uncomment the line below -->
<!-- I wrote automated tests -->
<!-- If JavaScript/TypeScript modules or builtins changed:
- [ ] I included a test for the new code, or existing tests cover it
- [ ] I ran my tests locally and they pass (`bun-debug test
test-file-name.test`)
-->
<!-- If Zig files changed:
- [ ] I checked the lifetime of memory allocated to verify it's (1)
freed and (2) only freed when it should be
- [ ] I included a test for the new code, or an existing test covers it
- [ ] JSValue used outside of the stack is either wrapped in a
JSC.Strong or is JSValueProtect'ed
- [ ] I wrote TypeScript/JavaScript tests and they pass locally
(`bun-debug test test-file-name.test`)
-->
<!-- If new methods, getters, or setters were added to a publicly
exposed class:
- [ ] I added TypeScript types for the new methods, getters, or setters
-->
<!-- If dependencies in tests changed:
- [ ] I made sure that specific versions of dependencies are used
instead of ranged or tagged versions
-->
<!-- If a new builtin ESM/CJS module was added:
- [ ] I updated Aliases in `module_loader.zig` to include the new module
- [ ] I added a test that imports the module
- [ ] I added a test that require() the module
-->
tests (bad currently)
---------
Co-authored-by: autofix-ci[bot] <114827586+autofix-ci[bot]@users.noreply.github.com>
Co-authored-by: Dylan Conway <dylan-conway@users.noreply.github.com>
Co-authored-by: Dylan Conway <dylan.conway567@gmail.com>
Co-authored-by: Jarred Sumner <jarred@jarredsumner.com>
Add a new reference-counted shared pointer type, `bun.ptr.Shared`.
Features:
* Can hold data of any type; doesn't require adding a `ref_count` field
* Reference count is an internal implementation detail; will never get
out of sync due to erroneous manipulation
* Supports weak pointers
* Supports optional pointers with no overhead (`Shared(?*T)` is the same
size as `Shared(*T)`)
* Has an atomic thread-safe version: `bun.ptr.AtomicShared`
* Defaults to `bun.default_allocator`, but can handle other allocators
as well, with both static and dynamic polymorphism
The following types are now deprecated and will eventually be removed:
* `bun.ptr.RefCount`
* `bun.ptr.ThreadSafeRefCount`
* `bun.ptr.RefPtr`
* `bun.ptr.WeakPtr`
(For internal tracking: fixes STAB-1011)
### What does this PR do?
Disable postMessage optimization when string is < 256 chars
If you're going to potentially use these strings as a property or
identifier, which is much more likely for short strings than long
strings, we shouldn't ban atomizing them and the cost of cloning isn't
so much in that case
### How did you verify your code works?
### What does this PR do?
in the name
### How did you verify your code works?
tests, but using ci to see if anything else broke
---------
Co-authored-by: autofix-ci[bot] <114827586+autofix-ci[bot]@users.noreply.github.com>
Co-authored-by: Jarred Sumner <jarred@jarredsumner.com>
## Summary
- Fixes a panic: "exact division produced remainder" that occurs when
reading files with odd number of bytes using utf16le/ucs2 encoding
- The crash happened in `encoding.zig:136` when
`std.mem.bytesAsSlice(u16, input)` was called on a byte slice with odd
length
- Fixed by properly checking for odd-length input and truncating to the
nearest even length
## Test plan
- Added regression tests in
`test/regression/issue/utf16-encoding-crash.test.ts`
- Tests verify that reading files with odd byte counts doesn't crash
- Tests verify correct truncation behavior matches Node.js expectations
- Verified edge cases (0, 1 byte inputs) return empty strings
## Root Cause
The original code checked `if (input.len / 2 == 0)` which only caught 0
and 1-byte inputs, but `std.mem.bytesAsSlice(u16, input)` panics on any
odd-length input (3, 5, 7, etc. bytes).
## Fix Details
- Changed condition to check `input.len % 2 != 0` for any odd length
- Truncate odd-length inputs to the nearest even length for valid UTF-16
processing
- Handle edge cases by returning empty string for 0 or 1-byte inputs
🤖 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>
Co-authored-by: Dylan Conway <dylan.conway567@gmail.com>
### What does this PR do?
Support sqlite in the Bun.sql API
Fixes#18951Fixes#19701
### How did you verify your code works?
tests
---------
Co-authored-by: autofix-ci[bot] <114827586+autofix-ci[bot]@users.noreply.github.com>
Co-authored-by: Jarred Sumner <jarred@jarredsumner.com>
Reverts oven-sh/bun#21962
`vm.ensureTerminationException` allocates a JSString, which is not safe
to do from a thread that doesn't own the API lock.
```ts
Bun Canary v1.2.21-canary.1 (f706382a) Linux x64 (baseline)
Linux Kernel v6.12.38 | musl
CPU: sse42 popcnt avx avx2 avx512
Args: "/var/lib/buildkite-agent/builds/ip-172-31-38-185/bun/bun/release/bun-linux-x64-musl-baseline-profile/bun-profile" "/var/lib/buildkite-agent/builds/ip-172-31-38-185/bun/bun/test/js/node/worker_threads"...
Features: bunfig http_server jsc tsconfig(3) tsconfig_paths workers_spawned(40) workers_terminated(34)
Builtins: "bun:main" "node:worker_threads"
Elapsed: 362ms | User: 518ms | Sys: 63ms
RSS: 0.34GB | Peak: 100.36MB | Commit: 0.34GB | Faults: 0 | Machine: 8.17GB
panic(main thread): Segmentation fault at address 0x0
oh no: Bun has crashed. This indicates a bug in Bun, not your code.
To send a redacted crash report to Bun's team,
please file a GitHub issue using the link below:
http://localhost:38809/1.2.21/Ba2f706382wNgkgUu11luEm6yX+lwy+Dgtt+oEurthoD8214mE___07+09DA2AA
6 | describe("Worker destruction", () => {
7 | const method = ["Bun.connect", "Bun.listen", "fetch"];
8 | describe.each(method)("bun when %s is used in a Worker that is terminating", method => {
9 | // fetch: ASAN failure
10 | test.skipIf(isBroken && method == "fetch")("exits cleanly", () => {
11 | expect([join(import.meta.dir, "worker_thread_check.ts"), method]).toRun();
^
error:
Command /var/lib/buildkite-agent/builds/ip-172-31-38-185/bun/bun/test/js/node/worker_threads/worker_thread_check.ts Bun.connect failed:
Spawned 10 workers RSS 79 MB
Spawned 10 workers RSS 87 MB
Spawned 10 workers RSS 90 MB
at <anonymous> (/var/lib/buildkite-agent/builds/ip-172-31-38-185/bun/bun/test/js/node/worker_threads/worker_destruction.test.ts:11:73)
✗ Worker destruction > bun when Bun.connect is used in a Worker that is terminating > exits cleanly [597.56ms]
✓ Worker destruction > bun when Bun.listen is used in a Worker that is terminating > exits cleanly [503.47ms]
» Worker destruction > bun when fetch is used in a Worker that is terminating > exits cleanly
1 pass
1 skip
1 fail
2 expect() calls
Ran 3 tests across 1 file. [1125.00ms]
======== Stack trace from GDB for bun-profile-28234.core: ========
Program terminated with signal SIGILL, Illegal instruction.
#0 crash_handler.crash () at crash_handler.zig:1523
[Current thread is 1 (LWP 28234)]
#0 crash_handler.crash () at crash_handler.zig:1523
#1 0x0000000002db77aa in crash_handler.crashHandler (reason=..., error_return_trace=0x0, begin_addr=...) at crash_handler.zig:471
#2 0x0000000002db2b55 in crash_handler.handleSegfaultPosix (sig=<optimized out>, info=<optimized out>) at crash_handler.zig:792
#3 0x0000000004716b58 in WTF::jscSignalHandler (sig=11, info=0x7ffe54051e90, ucontext=0x0) at vendor/WebKit/Source/WTF/wtf/threads/Signals.cpp:548
#4 <signal handler called>
#5 JSC::VM::currentThreadIsHoldingAPILock (this=0x148296c30000) at vendor/WebKit/Source/JavaScriptCore/runtime/VM.h:840
#6 JSC::sanitizeStackForVM (vm=...) at vendor/WebKit/Source/JavaScriptCore/runtime/VM.cpp:1369
#7 0x0000000003f4a060 in JSC::LocalAllocator::allocate(JSC::Heap&, unsigned long, JSC::GCDeferralContext*, JSC::AllocationFailureMode)::{lambda()#1}::operator()() const (this=<optimized out>) at cache/webkit-a73e665a39b281c5/include/JavaScriptCore/LocalAllocatorInlines.h:46
#8 JSC::FreeList::allocateWithCellSize<JSC::LocalAllocator::allocate(JSC::Heap&, unsigned long, JSC::GCDeferralContext*, JSC::AllocationFailureMode)::{lambda()#1}>(JSC::LocalAllocator::allocate(JSC::Heap&, unsigned long, JSC::GCDeferralContext*, JSC::AllocationFailureMode)::{lambda()#1} const&, unsigned long) (this=0x148296c38e48, cellSize=16, slowPath=...) at cache/webkit-a73e665a39b281c5/include/JavaScriptCore/FreeListInlines.h:46
#9 JSC::LocalAllocator::allocate (this=0x148296c38e30, heap=..., cellSize=16, deferralContext=0x0, failureMode=JSC::AllocationFailureMode::Assert) at cache/webkit-a73e665a39b281c5/include/JavaScriptCore/LocalAllocatorInlines.h:44
#10 JSC::GCClient::IsoSubspace::allocate (this=0x148296c38e30, vm=..., cellSize=16, deferralContext=0x0, failureMode=JSC::AllocationFailureMode::Assert) at cache/webkit-a73e665a39b281c5/include/JavaScriptCore/IsoSubspaceInlines.h:34
#11 JSC::tryAllocateCellHelper<JSC::JSString, (JSC::AllocationFailureMode)0> (vm=..., size=16, deferralContext=0x0) at cache/webkit-a73e665a39b281c5/include/JavaScriptCore/JSCellInlines.h:192
#12 JSC::allocateCell<JSC::JSString> (vm=..., size=16) at cache/webkit-a73e665a39b281c5/include/JavaScriptCore/JSCellInlines.h:212
#13 JSC::JSString::create (vm=..., value=...) at cache/webkit-a73e665a39b281c5/include/JavaScriptCore/JSString.h:204
#14 0x0000000004479ad1 in JSC::jsNontrivialString (vm=..., s=...) at vendor/WebKit/Source/JavaScriptCore/runtime/JSString.h:846
#15 JSC::VM::ensureTerminationException (this=0x148296c30000) at vendor/WebKit/Source/JavaScriptCore/runtime/VM.cpp:627
#16 JSGlobalObject__requestTermination (globalObject=<optimized out>) at ./build/release/./src/bun.js/bindings/ZigGlobalObject.cpp:3979
#17 0x0000000003405ab8 in bun.js.web_worker.notifyNeedTermination (this=0x542904f0d80) at /var/lib/buildkite-agent/builds/ip-172-31-16-28/bun/bun/src/bun.js/web_worker.zig:558
#18 0x0000000004362b6f in WebCore::Worker::terminate (this=0x984c900000000000) at ./src/bun.js/bindings/webcore/Worker.cpp:266
#19 WebCore::jsWorkerPrototypeFunction_terminateBody(JSC::JSGlobalObject*, JSC::CallFrame*, WebCore::JSWorker*)::{lambda()#1}::operator()() const (this=<optimized out>) at ./build/release/./src/bun.js/bindings/webcore/JSWorker.cpp:549
#20 WebCore::toJS<WebCore::IDLUndefined, WebCore::jsWorkerPrototypeFunction_terminateBody(JSC::JSGlobalObject*, JSC::CallFrame*, WebCore::JSWorker*)::{lambda()#1}>(JSC::JSGlobalObject&, JSC::ThrowScope&, WebCore::jsWorkerPrototypeFunction_terminateBody(JSC::JSGlobalObject*, JSC::CallFrame*, WebCore::JSWorker*)::{lambda()#1}&&) (lexicalGlobalObject=..., throwScope=..., valueOrFunctor=...) at ./src/bun.js/bindings/webcore/JSDOMConvertBase.h:174
#21 WebCore::jsWorkerPrototypeFunction_terminateBody (lexicalGlobalObject=<optimized out>, callFrame=<optimized out>, castedThis=<optimized out>) at ./build/release/./src/bun.js/bindings/webcore/JSWorker.cpp:549
#22 WebCore::IDLOperation<WebCore::JSWorker>::call<&WebCore::jsWorkerPrototypeFunction_terminateBody, (WebCore::CastedThisErrorBehavior)0> (lexicalGlobalObject=..., operationName=..., callFrame=...) at ./src/bun.js/bindings/webcore/JSDOMOperation.h:63
#23 WebCore::jsWorkerPrototypeFunction_terminate (lexicalGlobalObject=<optimized out>, callFrame=0x7ffe540536b8) at ./build/release/./src/bun.js/bindings/webcore/JSWorker.cpp:554
#24 0x000014825580c038 in ?? ()
#25 0x00007ffe540537b0 in ?? ()
#26 0x0000148255a626cb in ?? ()
#27 0x0000000000000000 in ?? ()
1 crashes reported during this test
```
## Summary
- Fixes a crash where invalid slice bounds caused a panic with message:
"start index N is larger than end index M"
- The issue occurred in `js_lexer.zig:767` when calculating string
literal content slice bounds
- Adds proper bounds checking to prevent slice bounds violations
- Includes regression test to prevent future occurrences
## Root Cause
The crash happened when `suffix_len` was larger than `lexer.end`,
causing the calculation `lexer.end - suffix_len` to result in a value
smaller than the `base` position. This created invalid slice bounds like
`[114..113]`.
## Solution
Added bounds checking to ensure:
1. `end_pos` is calculated safely: `if (lexer.end >= suffix_len)
lexer.end - suffix_len else lexer.end`
2. `slice_end` is always >= `base`: `@max(base, end_pos)`
## Test Plan
- [x] Added regression test in
`test/regression/issue/jsx-template-string-crash.test.ts`
- [x] Test verifies no crashes occur with JSX template string patterns
- [x] Verified normal template string functionality still works
- [x] All tests pass
🤖 Generated with [Claude Code](https://claude.ai/code)
---------
Co-authored-by: Jarred Sumner <jarred@jarredsumner.com>
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 namespace import objects inheriting from `Object.prototype`,
preventing prototype pollution and ensuring ES specification compliance.
```js
import * as mod from './mod.mjs'
Object.prototype.foo = function() {
console.log('hello');
}
mod.foo(); // This should throw, but succeeded before
```
original report: https://x.com/sapphi_red/status/1957843865722863876
### How did you verify your code works?
I added a test that verifies:
- `mod.maliciousFunction()` throws when
`Object.prototype.maliciousFunction` is added (prevents pollution)
- `__esModule` property still works
- Original exports remain accessible
---------
Co-authored-by: autofix-ci[bot] <114827586+autofix-ci[bot]@users.noreply.github.com>
### What does this PR do?
Calling `process.exit` inside a Web Worker now immediately notifies the
VM that it needs to terminate. Previously, `napi_call_function` would
return success in a Web Worker even if the JS code called
`process.exit`. Now it'll return `napi_pending_exception`.
### How did you verify your code works?
Ran Node's NAPI tests (`node-api/test_worker_terminate/test.js` now
passes) in addition to our own NAPI tests.
### What does this PR do?
Use
https://gist.github.com/christianparpart/d8a62cc1ab659194337d73e399004036
like we do in `bun run --filter`
### How did you verify your code works?
tried in next.js repo and in debug build it no longer flickers
---------
Co-authored-by: autofix-ci[bot] <114827586+autofix-ci[bot]@users.noreply.github.com>
## Summary
Fixes a critical segmentation fault crash occurring during NAPI
finalizer cleanup when finalizers trigger GC operations. This crash was
reported with `node-sqlite3` and other NAPI modules during process exit.
## Root Cause
The crash was caused by **iterator invalidation** in
`napi_env__::cleanup()`:
1. Range-based for loop iterates over `m_finalizers`
(std::unordered_set)
2. `boundFinalizer.call(this)` executes finalizer callbacks
3. Finalizers can trigger JavaScript execution and GC operations
4. GC can add/remove entries from `m_finalizers` during iteration
5. **Iterator invalidation** → undefined behavior → segfault
## Solution
Added `JSC::DeferGCForAWhile deferGC(m_vm)` scope during entire
finalizer cleanup to prevent any GC operations from occurring during
iteration.
### Why This Approach?
- **Addresses root cause**: Prevents GC entirely during critical section
- **Simple & safe**: One-line RAII fix using existing JSC patterns
- **Minimal impact**: Only affects process cleanup (not runtime
performance)
- **Proven pattern**: Already used elsewhere in Bun's codebase
- **Better than alternatives**: Cleaner than Node.js manual iterator
approach
## Testing
Added comprehensive test (`test_finalizer_iterator_invalidation.c`) that
reproduces the crash by:
- Creating finalizers that trigger GC operations
- Forcing JavaScript execution during finalization
- Allocating objects that can trigger more GC
- Calling process exit to trigger finalizer cleanup
**Before fix**: Segmentation fault
**After fix**: Clean exit ✅
## Files Changed
- `src/bun.js/bindings/napi.h`: Core fix + include
- `test/napi/napi-app/test_finalizer_iterator_invalidation.c`: Test
addon
- `test/napi/napi-app/binding.gyp`: Build config for test addon
- `test/regression/issue/napi-finalizer-crash.test.ts`: Integration test
## Test Plan
- [x] Reproduces original crash without fix
- [x] Passes cleanly with fix applied
- [x] Existing NAPI tests continue to pass
- [x] Manual testing with node-sqlite3 scenarios
🤖 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: Kai Tamkun <kai@tamkun.io>
## Summary
Fixes a crash in `napi_is_exception_pending` that occurs during
environment cleanup when finalizers call this function.
The crash manifested as:
```
panic: Aborted
- napi.h:192: napi_is_exception_pending
- napi.h:516: wrap_cleanup
- napi.h:273: napi_env__::cleanup
```
## Root Cause
Bun's implementation was using `DECLARE_THROW_SCOPE` during cleanup when
JavaScript execution is not safe, and didn't follow Node.js's approach
of avoiding `NAPI_PREAMBLE` for this function.
## Changes Made
1. **Remove `NAPI_PREAMBLE_NO_THROW_SCOPE`** - Node.js explicitly states
this function "must execute when there is a pending exception"
2. **Use `DECLARE_CATCH_SCOPE`** instead of `DECLARE_THROW_SCOPE` for
safety during cleanup
3. **Add safety check** `!env->isFinishingFinalizers()` before accessing
VM
4. **Add `napi_clear_last_error` function** to match Node.js
implementation
5. **Use `napi_clear_last_error`** instead of `napi_set_last_error` for
consistent behavior
## Test Plan
Created comprehensive test that:
- ✅ **Reproduces the original crash scenario** (finalizers calling
`napi_is_exception_pending`)
- ✅ **Verifies it no longer crashes in Bun**
- ✅ **Confirms behavior matches Node.js exactly**
### Test Results
**Before fix:** Would crash with `panic: Aborted` during cleanup
**After fix:**
```
Testing napi_is_exception_pending behavior...
1. Testing basic napi_is_exception_pending:
Status: 0 (should be 0 for napi_ok)
Result: false (should be false - no exception pending)
2. Testing with pending exception:
Exception was thrown as expected: Test exception
3. Testing finalizer scenario (the crash case):
Creating object with finalizer that calls napi_is_exception_pending...
Objects created. Forcing garbage collection...
Garbage collection completed.
napi_is_exception_pending in finalizer: status=0, result=false
[...5 finalizers ran successfully...]
SUCCESS: napi_is_exception_pending works correctly in all scenarios!
```
**Node.js comparison:** Identical output and behavior confirmed.
## Impact
- **Fixes crashes** in native addons that call
`napi_is_exception_pending` in finalizers
- **Improves Node.js compatibility** by aligning implementation approach
- **No breaking changes** - only fixes crash scenario, normal usage
unchanged
The fix aligns Bun's NAPI implementation with Node.js's proven approach
for safe exception checking during environment cleanup.
🤖 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 a panic that occurred when parsing malformed integrity data in
lockfiles. The issue was in `integrity.zig` where base64 decoding
attempted to write more bytes than the fixed-size digest buffer could
hold, causing `panic: index out of bounds: index 64, len 64`.
## Root Cause
The `Integrity.parse()` function tried to decode base64 data into a
fixed 64-byte buffer without validating that the decoded size wouldn't
exceed the buffer capacity. When malformed or oversized base64 integrity
strings were encountered in lockfiles, this caused an out-of-bounds
write.
## Fix
Added proper bounds checking in `src/install/integrity.zig`:
- Validates expected digest length before decoding
- Checks decoded size against buffer capacity using `calcSizeForSlice()`
- Only decodes into appropriately sized buffer slice based on hash
algorithm
- Returns `unknown` tag for malformed data instead of panicking
## Test Plan
- [x] Verified release binary crashes with malformed integrity data
- [x] Verified debug build with fix handles malformed data gracefully
- [x] Added comprehensive regression tests for all hash types (sha1,
sha256, sha384, sha512)
- [x] Confirmed normal lockfile parsing continues to work correctly
- [x] Tests pass: `bun bd test
test/regression/issue/integrity-base64-bounds-check.test.ts`
## Before/After
**Before**: `panic: index out of bounds: index 64, len 64`
**After**: Graceful handling with warning about malformed integrity data
🤖 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?
Solves https://github.com/oven-sh/bun/issues/21923
So: if on riscv64, bail out, and do not install the x86-64 version of
bun
### How did you verify your code works?
On my RISCV system:
```
git clone https://github.com/sanderjo/bun.git sjo-oven-sh-bun
cd sjo-oven-sh-bun/
git branch -a
git checkout origin/detect_and_refuse_riscv64
grep -irn riscv64 src/cli/install.sh
```
Yes, correct. And then:
```
sander@riscv:~/git/sjo-oven-sh-bun$ bash src/cli/install.sh
error: Not supported on riscv64
sander@riscv:~/git/sjo-oven-sh-bun$
```
Good.
Co-authored-by: sanderjo <sander.jonkers+github@github.com>
## Summary
Fixes a crash in Package.zig where top-level catalog strings weren't
being counted before appending to the string builder.
## Root Cause
The issue occurred in the `parseWithJSON` function where:
1. **Counting phase**: Only catalog strings in the "workspaces"
expression were counted via `lockfile.catalogs.parseCount()`
2. **Appending phase**: There was a conditional call to
`lockfile.catalogs.parseAppend()` for top-level JSON catalog strings
3. **Result**: String builder allocation was insufficient when top-level
catalog strings were processed
## Changes
- Added `lockfile.catalogs.parseCount(lockfile, json, &string_builder)`
in the counting phase to ensure top-level catalog strings are always
counted
- Added explanatory comment documenting why this counting is necessary
## Test Plan
- [x] Built debug version successfully
- [x] Verified bun-debug binary works correctly
- [ ] Should be tested with package.json files that have top-level
catalog configurations
🤖 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
- Add comprehensive documentation for `Bun.stripANSI()` utility function
in `docs/api/utils.md`
- Highlight significant performance advantages over npm `strip-ansi`
package (6-57x faster)
- Include usage examples and detailed benchmark comparisons
- Document performance improvements across different string sizes
## Test plan
- [x] Documentation follows existing format and style
- [x] Performance claims are backed by benchmark data from
`bench/snippets/strip-ansi.mjs`
- [x] Code examples are accurate and functional
🤖 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?
Fixes a duplicate output issue in `bun init` where `CLAUDE.md` was being
listed twice in the file creation summary.
Fixes#21468
**Problem:** When running `bun init`, the file creation output showed
`CLAUDE.md` twice
## How did you verify your code works?
<img width="946" height="287"
alt="1_00c7cd25-d5e4-489b-84d8-f72fb1752a67"
src="https://github.com/user-attachments/assets/4e51985d-8df1-4c6a-a824-ff9685548051"
/>
## Summary
This PR adds a new `--compile-argv` option to `bun build --compile` that
allows developers to embed runtime arguments into standalone
executables. The specified arguments are stored in the executable
metadata during compilation and provide **dual functionality**:
1. **🔧 Actually processed by Bun runtime** (like passing them on command
line)
2. **📊 Available in `process.execArgv`** (for application inspection)
This means flags like `--user-agent`, `--smol`, `--max-memory` will
actually take effect AND be visible to your application!
## Motivation & Use Cases
### 1. **Global User Agent for Web Scraping**
Perfect for @thdxr's opencode use case - the user agent actually gets
applied:
```bash
# Compile with custom user agent that ACTUALLY works
bun build --compile --compile-argv="--user-agent='OpenCode/1.0'" ./scraper.ts --outfile=opencode
# The user agent is applied by Bun runtime AND visible in execArgv
./opencode # All HTTP requests use the custom user agent!
```
### 2. **Memory-Optimized Builds**
Create builds with actual runtime memory optimizations:
```bash
# Compile with memory optimization that ACTUALLY takes effect
bun build --compile --compile-argv="--smol --max-memory=512mb" ./app.ts --outfile=app-optimized
# Bun runtime actually runs in smol mode with memory limit
```
### 3. **Performance & Debug Builds**
Different builds with different runtime characteristics:
```bash
# Production: optimized for memory
bun build --compile --compile-argv="--smol --gc-frequency=high" ./app.ts --outfile=app-prod
# Debug: with inspector enabled
bun build --compile --compile-argv="--inspect=0.0.0.0:9229" ./app.ts --outfile=app-debug
```
### 4. **Security & Network Configuration**
Embed security settings that actually apply:
```bash
# TLS and network settings that work
bun build --compile --compile-argv="--tls-min-version=1.3 --dns-timeout=5000" ./secure-app.ts
```
## How It Works
### Dual Processing Architecture
The implementation provides both behaviors:
```bash
# Compiled with: --compile-argv="--smol --user-agent=Bot/1.0"
./my-app --config=prod.json
```
**What happens:**
1. **🔧 Runtime Processing**: Bun processes `--smol` and
`--user-agent=Bot/1.0` as if passed on command line
2. **📊 Application Access**: Your app can inspect these via
`process.execArgv`
```javascript
// In your compiled application:
// 1. The flags actually took effect:
// - Bun is running in smol mode (--smol processed)
// - All HTTP requests use Bot/1.0 user agent (--user-agent processed)
// 2. You can also inspect what flags were used:
console.log(process.execArgv); // ["--smol", "--user-agent=Bot/1.0"]
console.log(process.argv); // ["./my-app", "--config=prod.json"]
// 3. Your application logic can adapt:
if (process.execArgv.includes("--smol")) {
console.log("Running in memory-optimized mode");
}
```
### Implementation Details
1. **Build Time**: Arguments stored in executable metadata
2. **Runtime Startup**:
- Arguments prepended to actual argv processing (so Bun processes them)
- Arguments also populate `process.execArgv` (so app can inspect them)
3. **Result**: Flags work as if passed on command line + visible to
application
## Example Usage
```bash
# User agent that actually works
bun build --compile --compile-argv="--user-agent='MyBot/1.0'" ./scraper.ts --outfile=scraper
# Memory optimization that actually applies
bun build --compile --compile-argv="--smol --max-memory=256mb" ./microservice.ts --outfile=micro
# Debug build with working inspector
bun build --compile --compile-argv="--inspect=127.0.0.1:9229" ./app.ts --outfile=app-debug
# Multiple working flags
bun build --compile --compile-argv="--smol --user-agent=Bot/1.0 --tls-min-version=1.3" ./secure-scraper.ts
```
## Runtime Verification
```javascript
// Check what runtime flags are active
const hasSmol = process.execArgv.includes("--smol");
const userAgent = process.execArgv.find(arg => arg.startsWith("--user-agent="))?.split("=")[1];
const maxMemory = process.execArgv.find(arg => arg.startsWith("--max-memory="))?.split("=")[1];
console.log("Memory optimized:", hasSmol);
console.log("User agent:", userAgent);
console.log("Memory limit:", maxMemory);
// These flags also actually took effect in the runtime!
```
## Changes Made
### Core Implementation
- **Arguments.zig**: Added `--compile-argv <STR>` flag with validation
- **StandaloneModuleGraph.zig**: Serialization/deserialization for
`compile_argv`
- **build_command.zig**: Pass `compile_argv` to module graph
- **cli.zig**: **Prepend arguments to actual argv processing** (so Bun
processes them)
- **node_process.zig**: **Populate `process.execArgv`** from stored
arguments
- **bun.zig**: Made `appendOptionsEnv()` public for reuse
### Testing
- **expectBundled.ts**: Added `compileArgv` test support
- **compile-argv.test.ts**: Tests verifying dual behavior
## Behavior
### Complete Dual Functionality
```javascript
// With --compile-argv="--smol --user-agent=TestBot/1.0":
// ✅ Runtime flags actually processed by Bun:
// - Memory usage optimized (--smol effect)
// - HTTP requests use TestBot/1.0 user agent (--user-agent effect)
// ✅ Flags visible to application:
process.execArgv // ["--smol", "--user-agent=TestBot/1.0"]
process.argv // ["./app", ...script-args] (unchanged)
```
## Backward Compatibility
- ✅ Purely additive feature - no breaking changes
- ✅ Optional flag - existing behavior unchanged when not used
- ✅ No impact on non-compile builds
## Perfect for @thdxr's Use Case!
```bash
# Compile opencode with working user agent
bun build --compile --compile-argv="--user-agent='OpenCode/1.0'" ./opencode.ts --outfile=opencode
# Results in:
# 1. All HTTP requests actually use OpenCode/1.0 user agent ✨
# 2. process.execArgv contains ["--user-agent=OpenCode/1.0"] for inspection ✨
```
The user agent will actually work in all HTTP requests made by the
compiled executable, not just be visible as metadata!
🚀 Generated with [Claude Code](https://claude.ai/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: Claude <claude@anthropic.ai>
## Summary
Fixes a prerequisite issue in #21792 where `Bun.serve()` incorrectly
rejected TLS arrays with exactly 1 object.
The original issue reports a WebSocket crash with multiple TLS configs,
but users first encounter this validation bug that prevents
single-element TLS arrays from working at all.
## Root Cause
The bug was in `ServerConfig.zig:918` where the condition checked for
exactly 1 element and threw an error:
```zig
if (value_iter.len == 1) {
return global.throwInvalidArguments("tls option expects at least 1 tls object", .{});
}
```
This prevented users from using the syntax: `tls: [{ cert, key,
serverName }]`
## Fix
Updated the validation logic to:
- Empty TLS arrays are ignored (treated as no TLS)
- Single-element TLS arrays work correctly for SNI
- Multi-element TLS arrays continue to work as before
```zig
if (value_iter.len == 0) {
// Empty TLS array means no TLS - this is valid
} else {
// Process the TLS configs...
}
```
## Testing
- ✅ All existing SSL tests still pass (16/16)
- ✅ New comprehensive regression test with 7 test cases
- ✅ Tests cover empty arrays, single configs, multiple configs, and
error cases
## Note
This fix addresses the validation issue that prevents users from
reaching the deeper WebSocket SNI crash mentioned in #21792. The crash
itself may require additional investigation, but this fix resolves the
immediate blocker that users encounter first.
---------
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>
