Bun 1.2, released January 22, 2025, made Node.js compatibility more systematic: instead of relying mainly on individual bug reports, Bun began porting and running large portions of Node.js’s own test suite with every change. The release says this work fixed thousands of bugs and pushed several Node modules above 90% test passing. That is substantial progress, not a promise that every Node.js application or native addon will work unchanged.
What Bun 1.2 changed about Node.js compatibility
Bun’s stated goal is to serve as a drop-in Node.js replacement. Its current compatibility documentation sets a useful expectation: “If a package works in Node.js but doesn’t work in Bun, we consider it a bug in Bun.” That is a compatibility policy, not a guarantee that every package already works.
Before this shift, compatibility work was described as a “wack-a-mole” process driven by GitHub reports. Bun began porting thousands of Node.js test files and running them for every Bun commit, catching differences closer to the APIs where they originate. Bun reported that several modules had more than 90% of their Node.js tests passing; this figure applies to those modules, not to all of Node.js or all npm packages.
Which Node.js APIs improved in Bun 1.2?
HTTP/2 servers and gRPC
Bun 1.2 added node:http2 server support, enabling applications that use HTTP/2 servers, including gRPC servers. There is an important platform caveat for reusePort: the release says its load-balancing behavior works as expected only on Linux. Windows and macOS do not load-balance HTTP connections in the same way.
#1 Best Overall
Compression with node:zlib
Bun rewrote node:zlib in native code and added Brotli support. In Bun’s own benchmark, inflateSync ran 2× faster than in Bun 1.1. This is a version-to-version vendor benchmark, not an independent measurement or a guarantee for every compression workload.
V8 heap snapshots
Bun added getHeapSnapshot() and writeHeapSnapshot() to node:v8. Developers can create heap snapshots and inspect Bun with Chrome DevTools, which helps diagnose memory use without implying Bun itself runs on V8.
Rank #2
Does Bun 1.2 support native Node.js addons?
Some addons depend on the engine beneath Node.js. Node.js uses V8, while Bun uses JavaScriptCore; as a result, older packages built against V8’s internal C++ APIs could not simply run in Bun. Bun 1.2 implemented V8’s public C++ API surface in JavaScriptCore, allowing packages such as cpu-features to work.
This did not amount to universal native-addon compatibility. Bun said many features were still missing and identified node-canvas@v2 and node-sqlite3 as future compatibility work. When assessing an application, check the particular addon and its engine/API dependency rather than assuming that success with JavaScript packages predicts native-module support.
The Tool Desk
Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →Rank #3
How strong are Bun 1.2’s performance claims?
Bun’s release benchmark reported Express serving up to 3× faster than Node.js, attributing the result to node:http compatibility work and HTTP-server optimization. “Up to” describes the result in Bun’s cited benchmark, not a general production expectation; real throughput depends on the application, workload, hardware and configuration.
What changed for lockfiles and Linux containers?
Text-based lockfile
Bun 1.2 moved from its binary bun.lockb direction to a text-based bun.lock file, while retaining npm-compatible package installation. Teams adopting the release should account for the lockfile format in version control and build workflows.
Rank #4
musl and Alpine
Bun added musl builds for Linux x64 and aarch64 and documented an Alpine Docker image. Bun recommends glibc unless musl is specifically needed, noting that musl can be slightly slower. Choose the image and libc target to match the deployment environment rather than treating Alpine as an automatic performance or compatibility upgrade.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.How to judge whether Bun 1.2 fits a Node.js project
Bun 1.2’s test-suite approach and expanded APIs make it a more credible Node.js alternative, but migration suitability still depends on the application’s dependencies and runtime requirements. Check these areas before switching:
Quick wins for a faster PC:
Repair Windows errors before they cause bigger problemsFix Now →Scan for outdated or missing drivers - takes under a minuteDriver Scan →- Node APIs: Identify the Node.js modules your application relies on, especially less common APIs, and exercise their actual code paths under Bun.
- Native addons: Determine whether each addon uses N-API or depends on V8-specific C++ interfaces; do not infer support from ordinary npm package installation.
- HTTP/2 and gRPC: Test the server and deployment platform, particularly if using
reusePortoutside Linux. - Compression and server performance: Benchmark your own workload. Bun’s zlib and Express figures are release benchmarks, not application-specific outcomes.
- Build workflow: Review how your team commits and consumes lockfiles when moving to
bun.lock. - Container target: Confirm whether the image requires glibc or musl and whether Alpine is a firm deployment constraint.
- Diagnostics: If heap snapshots are part of your workflow, verify the snapshot and Chrome DevTools process with your application.
What happened after Bun 1.2.0?
Bun v1.2.1 followed on January 27, 2025, fixing 32 bugs, including compatibility improvements involving node:fs, node:child_process and node:process. The patch shows that compatibility work continued after the 1.2.0 release; it does not establish compatibility beyond the versions and changes described here.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
