Bun's experimental Rust rewrite hit 99.8% test compatibility on Linux x64 glibc this week (HN thread, 600+ points). That's not a minor benchmark — it's the kind of number that signals "almost usable" for production CI, which is exactly what I've been waiting to hear before thinking seriously about switching.
My current GitHub Actions setup runs Node 22 with pnpm. It works, it's boring, and I have no pressing reason to change it. But Bun is fast enough on package install that I'd switch if the compatibility story held. So here's what I'm actually looking at before making any decision.
What 99.8% means and doesn't mean
Bun's test suite compatibility number is against Node.js's own test suite — thousands of tests across core APIs like fs, net, process, child_process, and so on. 99.8% passing sounds excellent. The 0.2% that fails could be anything from obscure edge cases no real code hits to the exact API your build tool relies on.
For my stack the relevant surface is narrow: pnpm install, pnpm build (Astro 5 SSG), and a handful of Node.js scripts that call filesystem APIs. None of those are exotic. The most likely compatibility risk is Astro's Vite internals — Vite does some unusual things with module resolution and worker threads. Whether Bun handles that cleanly is not something I can determine from a headline number.
The 99.8% figure is also Linux x64 glibc specifically. My CI runs on ubuntu-latest, which fits. macOS runners and Alpine-based containers (glibc vs. musl) are separate stories.
Why I haven't switched yet — the Playwright constraint
The bigger blocker isn't JavaScript compatibility. It's Playwright.
My publish workflow installs playwright==1.50.0 and runs Chromium to generate OG images and summary cards. That step is Python, not Bun. But the pnpm commands and Node.js scripts in the same workflow run under whichever Node/Bun runtime the runner uses. Mixing Bun as the JS runtime with the system Python calling Playwright is technically fine — they don't interact. The problem is the Bun install itself can take a few seconds to set up in CI, and pnpm under Bun sometimes behaves differently from pnpm under Node for global stores and lockfile resolution.
I've seen reports of pnpm install --frozen-lockfile behaving differently on Bun when workspace symlinks are involved. My monorepo has three Astro sites sharing packages under a pnpm workspace. That's exactly the kind of symlink-heavy setup where edge cases surface.
Until I've seen a clear "pnpm workspaces + Playwright + Bun" confirmation from someone running it in CI, I'm treating this as "watch, don't switch."
What would actually make me switch
Three conditions:
pnpm compatibility confirmation — specifically pnpm install --frozen-lockfile in a multi-package workspace completing identically to Node. Not just installing, but the lockfile hash matching what was generated under Node. If the lockfile drifts, CI fails in confusing ways.
Install time data — Bun is supposed to be meaningfully faster than Node + pnpm for install. I'd need to see a real comparison in GitHub Actions, not a local benchmark. CI runners have network variance that local benchmarks hide. A 20-second install becoming a 5-second install matters for a workflow that runs on every push; a 60-second install becoming a 50-second install doesn't.
Astro + Vite verified — Astro 5 builds under Bun should work, but Vite's worker thread usage and dynamic imports are the most likely failure points. I'd want to see this confirmed on Astro 5 specifically, not Astro 4 or a simple vanilla Vite project.
None of these are blockers in principle — they're just data I don't have yet. The Bun team has been responsive to compatibility reports, so my guess is this gets resolved over the next few months.
The pnpm + Node 22 status quo
For what it's worth, my current setup is: actions/setup-node@v4 with node-version: "22" and cache: "pnpm". Cold install on a fresh runner with the pnpm cache populated: roughly 30–40 seconds for the workspace. Warm (cache hit): under 10 seconds. The cache: "pnpm" option in actions/setup-node is the single most impactful change I've made to CI speed — it uses the pnpm store hash as the cache key and avoids re-downloading packages on repeat runs.
That setup works and I trust it. Switching to Bun for a marginal speed improvement on something that's already fast would be solving a problem I don't have.
What I'm actually doing this week
Watching the HN thread, not running benchmarks. If you're running Bun in a pnpm workspace with Astro 5 and GitHub Actions, I'd genuinely like to know how it went.
The Rust rewrite milestone matters because it signals intent — the Bun team is serious about compatibility, not just performance. At 99.8% on Linux x64, the gap between "interesting experiment" and "production CI" is closing. I'll revisit when the Astro and Playwright stories are clearer.
Part of an ongoing 6-month experiment running three AI-curated directory sites. The technical claims here are real; this article was AI-assisted.
SOCIAL SHARE CARD GENERATOR