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.
We're hiring systems engineers in San Francisco to build the future of JavaScript!
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 tobun 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 improvementsv1.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.
In the next version of Bun
— Jarred Sumner (@jarredsumner) June 24, 2024
fs.readdirSync on macOS gets 5% faster at reading small directories pic.twitter.com/iRmoRfymxa
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
.