### What does this PR do?
**This PR is created because [the previous PR I
opened](https://github.com/oven-sh/bun/pull/21728) had some concerning
issues.** Thanks @Jarred-Sumner for the help.
The goal of this PR is to introduce PUB/SUB functionality to the
built-in Redis client. Based on the fact that the current Redis API does
not appear to have compatibility with `io-redis` or `redis-node`, I've
decided to do away with existing APIs and API compatibility with these
existing libraries.
I have decided to base my implementation on the [`redis-node` pub/sub
API](https://github.com/redis/node-redis/blob/master/docs/pub-sub.md).
#### Random Things That Happened
- [x] Refactored the build scripts so that `valgrind` can be disabled.
- [x] Added a `numeric` namespace in `harness.ts` with useful
mathematical libraries.
- [x] Added a mechanism in `cppbind.ts` to disable static assertions
(specifically to allow `check_slow` even when returning a `JSValue`).
Implemented via `// NOLINT[NEXTLINE]?\(.*\)` macros.
- [x] Fixed inconsistencies in error handling of `JSMap`.
### How did you verify your code works?
I've written a set of unit tests to hopefully catch the major use-cases
of this feature. They all appear to pass.
#### Future Improvements
I would have a lot more confidence in our Redis implementation if we
tested it with a test suite running over a network which emulates a high
network failure rate. There are large amounts of edge cases that are
worthwhile to grab, but I think we can roll that out in a future PR.
### Future Tasks
- [ ] Tests over flaky network
- [ ] Use the custom private members over `_<member>`.
---------
Co-authored-by: Jarred Sumner <jarred@jarredsumner.com>
### What does this PR do?
### How did you verify your code works?
---------
Co-authored-by: Claude Bot <claude-bot@bun.sh>
Co-authored-by: autofix-ci[bot] <114827586+autofix-ci[bot]@users.noreply.github.com>
## Summary
- Fixes unnecessary regeneration of `bun_dependency_versions.h` on every
CMake run
- Only writes the header file when content actually changes
## Test plan
Tested locally by running CMake configuration multiple times:
1. First run generates the file (shows "Updated dependency versions
header")
2. Subsequent runs skip writing (shows "Dependency versions header
unchanged")
3. File modification timestamp remains unchanged when content is the
same
4. File is properly regenerated when deleted or when content changes
🤖 Generated with [Claude Code](https://claude.ai/code)
Co-authored-by: Claude Bot <claude-bot@bun.sh>
Co-authored-by: Claude <noreply@anthropic.com>
### What does this PR do?
Evidently, Ubuntu turns them on by default.
Claude:
```
> What is the typical overhead for glibcxx assertions?
⏺ The overhead of glibc/libstdc++ assertions can be significant, especially in
performance-critical code:
Typical Overhead Ranges:
libstdc++ (C++ standard library) assertions:
- 5-15% overall performance impact in typical applications
- Up to 30-50% in container-heavy code (vectors, maps, etc.)
- Iterator validity checks are particularly expensive
glibc (C library) assertions:
- 2-8% overall impact in typical applications
- Up to 20% in malloc/free intensive code
- Heap consistency checks, buffer overflow detection
```
## Summary
This PR introduces a CMake-generated header file containing all
dependency versions, eliminating the need for C++ code to depend on
Zig-exported version constants.
## Changes
- **New CMake script**: `cmake/tools/GenerateDependencyVersions.cmake`
that:
- Reads versions from the existing `generated_versions_list.zig` file
- Extracts semantic versions from header files where available
(libdeflate, zlib)
- Generates `bun_dependency_versions.h` with all dependency versions as
compile-time constants
- **Updated BunProcess.cpp**:
- Now includes the CMake-generated `bun_dependency_versions.h`
- Uses `BUN_VERSION_*` constants instead of `Bun__versions_*`
- Removes dependency on Zig-exported version constants
- **Build system updates**:
- Added `GenerateDependencyVersions` to main CMakeLists.txt
- Added build directory to include paths in BuildBun.cmake
## Benefits
✅ Single source of truth for dependency versions
✅ Versions accessible from C++ without Zig exports
✅ Automatic regeneration during CMake configuration
✅ Semantic versions shown where available (e.g., zlib 1.2.8 instead of
commit hash)
✅ Debug output file for verification
## Test Results
Verified that `process.versions` correctly shows all dependency
versions:
```javascript
$ bun -e "console.log(JSON.stringify(process.versions, null, 2))"
{
"node": "24.3.0",
"bun": "1.2.22-debug",
"boringssl": "29a2cd359458c9384694b75456026e4b57e3e567",
"libarchive": "898dc8319355b7e985f68a9819f182aaed61b53a",
"mimalloc": "4c283af60cdae205df5a872530c77e2a6a307d43",
"webkit": "0ddf6f47af0a9782a354f61e06d7f83d097d9f84",
"zlib": "1.2.8",
"libdeflate": "1.24",
// ... all versions present and correct
}
```
## Generated Files
- `build/debug/bun_dependency_versions.h` - Header file with version
constants
- `build/debug/bun_dependency_versions_debug.txt` - Human-readable
version list
🤖 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?
Enables async stack traces
### How did you verify your code works?
Added tests
---------
Co-authored-by: autofix-ci[bot] <114827586+autofix-ci[bot]@users.noreply.github.com>
### What does this PR do?
### How did you verify your code works?
---------
Co-authored-by: autofix-ci[bot] <114827586+autofix-ci[bot]@users.noreply.github.com>
Co-authored-by: Claude Bot <claude-bot@bun.sh>
Co-authored-by: Claude <noreply@anthropic.com>
ebe0cdac31..e0b7c318f3
It hides it in typeInfo even in the current file, unlike private
declarations which are only hidden in other files.
This allows you to formatted print a type with private fields, but the
private fields are not shown. The alternative would be to allow
accessing private fields through `@field()` but that looked like it was
going to be more complicated (need to add an argument to
structFieldVal/structFieldPtr which are called by fieldVal/fieldPtr
which have 36 callsites)
---------
Co-authored-by: taylor.fish <contact@taylor.fish>
ZLS was tested manually and works with private fields (after restarting)
Zig diff:
d1a4e0b0dd..ebe0cdac31
ZLS diff:
15730e8e5d..3733f39c8d
Increases `zig build check` time by maybe 10ms?
---------
Co-authored-by: autofix-ci[bot] <114827586+autofix-ci[bot]@users.noreply.github.com>
### What does this PR do?
### How did you verify your code works?
---------
Co-authored-by: Jarred-Sumner <709451+Jarred-Sumner@users.noreply.github.com>
Co-authored-by: autofix-ci[bot] <114827586+autofix-ci[bot]@users.noreply.github.com>
## Summary
- Updates WebKit commit from `684d4551ce5f62683476409d7402424e0f6eafb5`
to `aa4997abc9126f5a7557c9ecb7e8104779d87ec4`
- Build completed successfully with no errors
- Verified functionality with hello world test
## Test plan
- [x] Build completed successfully
- [x] Hello world test passes with `bun bd`
- [x] No build errors encountered
🤖 Generated with [Claude Code](https://claude.ai/code)
Co-authored-by: Claude Bot <claude-bot@bun.sh>
Co-authored-by: Claude <noreply@anthropic.com>
## Summary
- Updates WebKit from 75f6499 to eb92990 (latest release from
oven-sh/webkit)
- This brings in the latest WebKit improvements and fixes
## Test plan
- [ ] Verify the build completes successfully
- [ ] Run existing test suite to ensure no regressions
🤖 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: Jarred Sumner <jarred@jarredsumner.com>
Co-authored-by: autofix-ci[bot] <114827586+autofix-ci[bot]@users.noreply.github.com>
### What does this PR do?
<!-- **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.
-->
### How did you verify your code works?
ran fuzzy-wuzzy.test.ts
<!-- **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
-->
### What does this PR do?
Lets us write and run unit tests directly in Zig.
Running Zig unit tests in CI is blocked by https://github.com/ziglang/zig/issues/23281. We can un-comment relevant code once this is fixed.
#### Workflow
> I'll finish writing this up later, but some initial points are below.
> Tl;Dr: `bun build:test`
Test binaries can be made for any kind of build. They are called `<bun>-test` and live next to their corresponding `bun` bin. For example, debug tests compile to `build/debug/bun-debug-test`.
Test binaries re-use most cmake/zig build steps from normal bun binaries, so building one after a normal bun build is pretty fast.
### How did you verify your code works?
I tested that my tests run tests.