Bootstrapping Bun

Summary

This article describes my journey building the Bun JavaScript toolkit without relying on any of its usual binary dependencies— namely itself. It all started when I wanted to try OpenCode for LLM-assisted coding. I found that it wasn’t easy to install—my distro packaged neither OpenCode itself, nor Bun, the JavaScript runtime used by OpenCode. The aur didn’t come to the rescue either as the latest revision of the Bun package failed to build. Note: Bun was packaged for Arch Linux on 2025-12-30 🎉! However Debian, Fedora, and Ubuntu still do not package it. I also uncovered an unfortunate dependency: there was no clearly documented process for bootstrapping Bun; its build process unabashedly invokes the Bun CLI, assuming it was previously built. The development Dockerfiles and CI scripts for the Bun repo simply download the binary from a prior revision. I’ll admit that I 99% trust binaries built by open source GitHub actions. However I completely trust packages built by myself or signed by my distro’s maintainers. I decided to pursue that incremental 1% (since maybe others could find it useful too). Exploratory work I didn’t have Bun on my system, but I did have Node. My first thought was to create some bun-wrapper script that would snitch on how and from where it was invoked. The script would also evolve to try to fulfill the calls it was receiving using alternative tools. I reasoned that this way of logging the dependencies that the build scripts have on Bun in practice would be faster than reading through lots of code. In the end a mixture of techniques was needed. The wrapper script was useful for getting the big picture of what subcommands were needed, but it was hard to produce the output expected by the script’s callers without reading the callsites. Becoming more familiar with the build scripts also gave me some idea of the scale of the task that I was previously only guessing at (it seemed manageable). Bun’s filling What follows is an edited version of an RFC t...