FAQ

Is Bun production-ready?

Yes — adopted within boundaries. Bun is MIT-licensed open source (written in Zig), and many services run it in production. The verdict should come from your own acceptance, not marketing: run type checks, tests, target-environment startups, load tests, and rollback drills per the production baseline. Conservative teams can start by replacing only package management and tests.

Does Bun replace npm?

bun install is a complete package manager, but the two can coexist during migration: keep the old lockfile through review, then keep exactly one authoritative lockfile after the switch is approved. See Migrate from Node.js.

Does Bun type-check TypeScript?

No. Bun strips types and executes; it does no static checking. Always keep a tsc --noEmit script in the repo and in CI — see Runtime.

How is Windows support?

Windows 10 version 1809 and newer, with official native builds. Some APIs behave differently or are not yet implemented on Windows — test subprocess, signal, and filesystem-path behavior on a real Windows target. Installation notes are in the quickstart.

bun.lock vs bun.lockb?

bun.lockb was the old binary format; since 1.2.0 the default is the text bun.lock (diffable, reviewable). New projects only get bun.lock; older projects should migrate and delete the legacy file. Background in the version matrix.

Must an existing Node.js project migrate all at once?

No — and it shouldn't. Adopt in parallel: scripts first, then package management, then tests, and the production runtime last; each stage has pass conditions and a rollback path. The full stage table is in Migrate from Node.js.

Do .node native addons work?

Bun implements Node-API, and many native addons work — but not all. Projects with native dependencies should run minimal load-and-function tests on the target OS/CPU before scoping the migration; record failures in known issues or the project migration doc.

With Bun, should Next.js / Vite projects switch build chains?

Not on your own initiative. The framework's official build commands remain the source of truth; Bun can handle package management, script execution, and even run framework CLIs via bun --bun, but builds stay on the framework's own pipeline. See the decision tables in Ecosystem decisions.

Bun or Deno?

Decide by permission model, package ecosystem, and deployment shape — not microbenchmarks: default sandbox → Deno, npm compatibility with one toolchain → Bun, heavy native addons and LTS → Node. Full comparison: Compare with Node.js and Deno.

A flag or API doesn't exist on my version?

Run bun --version, then check the version matrix for the minimum version; if behavior still doesn't line up, follow the troubleshooting order in Common errors.

Official references: Bun documentation, oven-sh/bun.