Bun v1.1.17

Bun v1.1.17 is here! This release fixes 4 bugs. Fixes a crash in bun repl. Makes fs.readdirSync 5% faster on macOS in small directories. Fixes "ws" module not calling the callback in "send" method. Fixes a crash when reading a corrupted lockfile in bun install. Makes macOS event loop slightly faster.

Previous releases

• v1.1.16 fixes 41 bugs (addressing 221 👍). lcov code coverage reports in bun test, Install dependencies from private git repositories including Gitlab and Bitbucket. Buffer.from(string, "base64") gets 6x - 30x faster on large input. Bug fixes to bun patch, bun install, N-AIi addons, transpiler bugfixes and Node.js compatibility improvements.
• v1.1.10 fixes 20 bugs. 2x faster uncached bun install on Windows. fetch() uses up to 2.8x less memory. Several bugfixes to bun install, sourcemaps, Windows reliability improvements and Node.js compatibility improvements
• v1.1.0 Bundows. Windows support is here!

To install Bun

curl -fsSL https://bun.sh/install | bash

npm install -g bun

powershell -c "irm bun.sh/install.ps1|iex"

scoop install bun

brew tap oven-sh/bun

brew install bun

docker pull oven/bun

docker run --rm --init --ulimit memlock=-1:-1 oven/bun

To upgrade Bun

bun upgrade

Fixed: crash in bun repl

In Bun v1.1.16, we upgraded the version of Zig from 0.12.0 to 0.13.0. One of the changes in Zig addressed a bug where immutable strings were being placed into the executable's data segment instead of the read-only data segment (.rodata).

This bug, unfortunately, was something that Bun unintentionally relied on.

bun repl is an alias of bunx bun-repl, which is an unofficial npm package we are planning to rewrite.

When aliasing bun repl to bunx bun-repl, we were mutating a string that was supposed to be immutable, and due to our poor test coverage of bun repl, we didn't catch this bug until it was too late.

This release fixes the crash in bun repl and also adds a regression test to prevent this from happening again.

5% faster fs.readdirSync on macOS in small directories

We've optimized the fs.readdirSync method to be 5% faster on macOS in small directories.

When calling the macOS getdirentries64 API, the XNU kernel adds a flag to the end of the buffer to indicate it has reached the end of the list of directory entries.

getdirentries64_flags_t *gdeflags =
    (getdirentries64_flags_t *)(dirp->dd_buf + dirp->dd_len -
    sizeof(getdirentries64_flags_t));
*gdeflags = 0;
dirp->dd_size = (long)__getdirentries64(dirp->dd_fd,
    dirp->dd_buf, dirp->dd_len, &dirp->dd_td->seekoff);
if (dirp->dd_size >= 0 &&
    dirp->dd_size <= dirp->dd_len - sizeof(getdirentries64_flags_t)) {
  if (*gdeflags & GETDIRENTRIES64_EOF) {
    dirp->dd_flags |= __DTF_ATEND;
  }
}

Previously, Bun was not checking this flag and instead would call getdirentries64 an extra time, which is an unnecessary system call in every place we read the contents of a directory. Now, we check the flag and avoid the extra system call.

Fixed: "ws" module not calling the callback in "send" method

When using a WebSocket from the "ws" module, the send method would not call the callback if the message was successfully sent. This has been fixed.

import { WebSocket } from "ws";
const ws = new WebSocket("ws://www.host.com/path");
ws.send("Hello", (err) => {
  if (err) {
    console.error("Failed to send message:", err);
  } else {
    console.log("Message sent successfully");
  }
});

Previously, the callback would never be called, which impacted libraries relying on the callback. This has been fixed.

Fixed: rare crash when reading a corrupted lockfile in bun install

A bug where Bun would potentially crash when reading a corrupted bun.lockb file in bun install has been fixed. We added bounds checking and earlier integer underflow/overflow checks to prevent this from happening. We added similar checks when reading cached npm registry manifests as well.

macOS event loop gets slightly faster

Every time background work completes in the event loop, the background thread dispatches a message to wake up the main thread. It's sort of like saying "Hey, wake up! I finished my work!". This step - waking up the main thread - gets very slightly faster on macOS in this release, thanks to some code we borrowed from libxev. Specifically, we no longer need to allocate memory for each message we send to wake up the main thread.

This change also impacts bun build.