Bun

Bun v1.1.1

Jarred Sumner · April 4, 2024

Bun is an incredibly fast JavaScript runtime, bundler, transpiler, and package manager — all in one.

Bun v1.1.1 fixes 20 bugs (addressing 60 👍 reactions). Add subshell and positional argument support to Bun Shell, fixing an issue with bun install + sharp on Windows. Printed source code in errors no longer fill up your terminal. Upgrades JavaScriptCore, which includes performance improvements to RegExp, typed arrays, String indexOf and String replace. Error objects and JIT'd function calls use less memory. Fixes several bugs with bun install on Windows. Fixes a bug with Bun.serve() on Windows. Fixes a TOML parser bug impacting escape sequences and windows paths in .toml files.

Previous releases

  • v1.1.0 Bundows. Windows support is here! Plus, JSON IPC Node <-> Bun.
  • v1.0.35 Fixes 13 bugs. Adds support for fs.openAsBlob and fs.opendir, fixes edgecase in bun install with multiple bin entries in package.json, fixes bun build --target bun encoding, fixes bug with process.stdin & process.stdout, fixes bug in http2, fixes bug with .env in bun run, fixes various Bun shell bugs and improves Node.js compatibility.

To install Bun:

curl
npm
powershell
scoop
brew
docker
curl
curl -fsSL https://bun.sh/install | bash
npm
npm install -g bun
powershell
powershell -c "irm bun.sh/install.ps1|iex"
scoop
scoop install bun
brew
brew tap oven-sh/bun
brew install bun
docker
docker pull oven/bun
docker run --rm --init --ulimit memlock=-1:-1 oven/bun

To upgrade Bun:

bun upgrade

Windows support improvements

Fixed: bun install failed to install sharp on Windows

Sharp would not install correctly on Windows due to an unimplemented feature in Bun Shell (which powers lifecycle scripts on Windows). This unimplemented feature has been implemented! Subshells are now supported in Bun Shell.

Our test suite will catch this bug in the future

Fixed: bun install hanging on Windows

A bug that could cause bun install to hang for awhile has been fixed.

This bug happened when ERROR_DELETE_PENDING was returned by a Windows API. When a folder or file is being deleted but hasn't been fully deleted yet, Windows sometimes returns ERROR_DELETE_PENDING. The zig standard library handled this by sleeping for 1ms and then retrying the delete. This causes a race condition when one thread has the handle open and another thread is trying to delete the file. The other thread goes to sleep in a loop forever, and the other thread never gets the chance to delete the file.

Thanks to @gvilums for fixing this issue.

Fixed: spurious "Install failed" errors in bun install on Windows

A bug that could cause spurious "Install failed" errors in bun install has been fixed. This most frequently occurred when installing many packages simultaneously.

A similar bug involving @scoped/package scoped packages was also fixed.

Why did this happen?

Permissions in Windows are a bit weird. Opened file handles have a "Sharing Mode", which prevents other file handles from being opened on the same file without the same permissions. In the zig standard library, the ERROR_SHARING_VIOLATION error was not handled correctly. Separately, certain functions were also not requesting the same "Sharing Mode", which causes the ERROR_SHARING_VIOLATION error. If you've been unable to delete a file on Windows without closing applications, this is frequently the cause.

Thanks to @gvilums for fixing this issue.

Fixed: Workspace linking bug on Windows

A bug where bun install could return error: Unexpected while linking a workspace has been fixed.

This was caused by passing an incorrectly formatted filesystem path to a Windows API.

Fixed: "unable to find executable" in bunx

A bug where running bunx <package> sometimes returned error: unable to find executable when it definitely should have been able to find the executable has been fixed.

The bug was caused by a cache invalidation bug in bunx. bunx was checking the package.json of the target package instead of the generated package.json that adds the target package as a dependency. The filesystem's creation time for that file may come from the original time the package was published to npm, which means it would virtually always invalidate the executable. Separately, there was another bug where bunx would check the creation time of the package.json twice, first when trying to use the cached verison and a second time after newly installing the package. Checking that second time is unnecessary because it was newly created.

Fixed: "Failed to install" error with Git dependencies

A bug where bun install would fail to clone or checkout a git repository with a dependency that was a Git repository has been fixed. This bug was caused by assuming the current working directory of the target package continued to have a valid file descriptor when the git clone or git checkout command was run. We switched it to use an absolute filesystem path instead, via the -C flag in git.

Thanks to @gvilums for fixing this issue.

Fixed: Spurious error when pressing CTRL+C in bun init

An error that would occur when pressing CTRL+C in bun init has been fixed.

Fixed: npm install -g bun should work now on Windows

Sorry. Please let us know if you're still having issues with npm install -g bun on Windows.

Runtime improvements

Truncated source code previews in error traces

When a top-level exception is thrown, Bun prints relevant source code to help you debug the error faster.

Normally, it looks like this:

1 | function oops() {
2 |   throw new Error("Woopsie woops!");
            ^
error: Woopsie woops!
      at oops (woopsie.js:2:9)
      at woopsie.js:5:1

However, what happens if the error is in a minified file? It would look something like this:

1 | function oops() {
2 | var h=1,t=2,m=3,x=4,m={o:{n:{t:{a:[{n: a}, {b: "uffalos"},() => {throw new Error("Woopsie woops!")}]}}}},j=q.u.e.r.y[0];such();minified();

error: Woopsie woops!
      at oops (woopsie.js:2:9)
      at woopsie.js:5:1

Some libraries publish minified source code. Most minifiers try to pack as much code as possible on a single line to reduce the byte count over the wire. Trying to print that to your terminal is...messy.

Previously, Bun would just dump the nearest 4 line(s) to your terminal. Now, we truncate the source code up to 1024 bytes per line. If the code is longer than 512 bytes, we also hide the divot ^ character since that ends up being quite a lot of whitespace. This makes it easier to read the error message.

JavaScriptCore upgrade

We've upgraded JavaScriptCore to the latest version, and there are a handful of performance and memory improvements in it.

Bugfixes:

  • A bug with the source location of member expressions with multiple new keywords has been fixed, thanks to @alexey - #27567fb2a9f3

Fixed: TOML parsing bug with escape sequences and Windows filesystem paths

A bug where Bun's TOML parser did not properly handle escape sequences and Windows filesystem paths has been fixed and we've added more tests to prevent this from happening again.

Fixed: Crash when node:vm throws an exception across global objects

A crash that could occur when code run in a node:vm context threw an exception to be handled by the main global object has been fixed.

This crash was cuased by assuming the global object was the same one as the main global object.

Fixed: process.dlopen now supports file: URLs

process.dlopen in Bun now supports loading shared libraries from file: URLs. file: URLs passed to process.dlopen are automatically translated to a filesystem path.

Fixed: ResolveMessage.message and BuildMessage.message are now writable

When trying to use ESLint in Bun, sometimes it would throw an error saying "Attempt to write to read-only property 'message'". This was caused by the message property being read-only in the ResolveMessage and BuildMessage classes in Bun. This isn't a great fix, BuildMessage and ResolveMessage should really extend Error instead of being their own classes - but it's a fix nonetheless.

Bun Shell improvements

Bun Shell powers package.json scripts in bun run and lifecycle scripts in bun install on Windows.

Subshells

Bun Shell now supports subshells.

import { $ } from "bun";

await $`echo hey $(echo hi)`;
// > hey hi

Subshells are frequently used to compose multiple commands into a single command.

On Windows, this also means bun run package.json scripts now support subshells.

Thanks to @zackradisic for implementing this.

Positional arguments with $0 $1 $2 through $9

Bun Shell now supports positional arguments with $0 $1 $2 through $9.

Running the following script:

import { $ } from "bun";

await $`echo $0 $1 $2 $3 $4 $5 $6 $7 $8 $9`;

From Bun Shell will print:

bun ./script.ts hello world foo bar baz
bun ./script.ts hello world foo bar baz

Previously, this would have printed:

bun ./script.ts hello world foo bar baz
$0 $1 $2 $3 $4 $5 $6 $7 $8 $9

Thanks to @nektro for implementing this.

Thank you to 8 contributors!