Bun 1.3.6: native JSONC, Archive API, esbuild metafile — what full‑stack teams should do now

Summary

• On January 13, 2026 Bun 1.3.6 shipped a set of practical tooling and runtime features (native JSONC parsing, a built‑in tar archive API, esbuild‑compatible metafile output) plus multiple performance and compatibility fixes. These are immediately relevant to teams using Bun as a runtime, bundler or CI builder because they reduce third‑party dependencies, improve bundle analysis parity with esbuild, and close subtle security and compatibility gaps. (bun.com)

What changed (high impact)

• Bun.JSONC: native parsing for JSON with comments (tsconfig.json, VS Code settings). Impact: you can drop small JSONC parsing deps and parse configurations reliably and faster at runtime.
• Bun.Archive: built‑in API to create/extract tar(.gz) archives. Impact: fewer external tools for packaging and reproducible single‑file build artifacts; better performance for packaging tasks.
• Bun.build metafile: adds an esbuild‑compatible metafile option. Impact: you can produce meta.json from Bun builds and reuse existing bundle‑analysis tools (squoosh, bundlephobia-style checks) without custom adapters.
• Response.json and JSON serialization perf: Response.json() parity with manual JSON.stringify + Response; other SIMD-accelerated improvements reduce serialization and buffer operations cost in high‑throughput services.
• WebSocket proxy & S3 Requester Pays: fixes for enterprise proxy environments and requester‑pays S3 access in Bun’s S3 client.
• Security/compatibility fixes: path‑traversal checks during tar extraction and multiple bundler/build bug fixes that affect edge deployments and single-file executables.

Why this matters for full‑stack teams

• Fewer runtime dependencies: native JSONC and archive APIs reduce the attack surface and dependency maintenance for config / packaging pipelines.
• Better CI and bundle tooling parity: the esbuild metafile makes Bun builds compatible with established analysis pipelines (CI size gates, automated chunk inspection).
• Faster server responses and build steps: serialization and buffer speedups can measurably lower latency and CI runtime for I/O‑heavy services.
• Enterprise readiness: proxy support for WebSocket and Requester Pays handling closes gaps that previously required custom workarounds when running in corporate or cloud‑restricted environments.
• Security: tar extraction hardening prevents a common vector for supply‑chain/packaging errors.

Actionable checklist (concrete, low‑risk rollout)

1. Evaluate in a feature branch
   • Upgrade to Bun 1.3.6 in a branch of your CI image (docker image or VM), run full test suites and smoke tests. Measure build times and key benchmarks (bundle build, server start, API latency).
2. Replace small dependencies intentionally
   • Where you currently parse tsconfig.json / .vscode settings with a 3rd‑party JSONC parser, run a targeted replacement test using Bun.JSONC.parse() and confirm identical behavior (comments, trailing commas, ordering).
3. Add metafile output to builds
   • Enable metafile in bun.build/bun build (metafile: true or --metafile) and feed the generated JSON to your existing bundle analyzer or CI size gate. Validate that chunk maps and size attributions match expectations.
4. Test archive flows and secure extraction
   • If you produce or consume tarballs in build/release pipelines, switch to Bun.Archive for create/extract and run extraction path‑traversal tests (attempted symlink escapes, absolute paths) to confirm Bun rejects unsafe cases.
5. Verify WebSocket + proxy scenarios
   • If you operate in environments with corporate HTTP/HTTPS proxies, validate Bun’s WebSocket proxy option for both wss/ws and authenticated proxies.
6. Audit native modules and single-file execs
   • If you use embedded .node addons or single‑file executables, run full integration tests—notes in the release indicate improved loading but also fixes for previous edge cases.
7. Performance and monitoring
   • Benchmark Response.json() and heavy JSON paths in staging. Add observability flags (build durations, serialization latency) to ensure regressions are caught.
8. Rollout strategy
   • Canary the runtime for a small percentage of traffic or CI agents for 48–72 hours; monitor errors, cold starts, and bundle analysis reports; then promote.

Risks and caveats

• Not a drop‑in for everyone: if your stack depends on very specific esbuild quirks or native addon behavior, test thoroughly; metafile parity helps analysis but does not guarantee identical loader semantics.
• Native dependencies and N‑API: single‑file executables and embedded .node behavior improved, but native modules still require careful testing across Linux, macOS and Windows builds.
• Security posture: the tar extraction fix is a security hardening—treat it as a positive, but audit existing archives in case they relied on prior, lenient behavior.

Bottom line Bun 1.3.6 is a practical, low‑friction release for teams using Bun as a runtime or builder: use the new JSONC and metafile features to simplify configs and integrate Bun builds into existing CI/analysis, test the archive and proxy improvements, and canary the runtime while monitoring serialization and bundle metrics. The release reduces dependency surface and improves observability parity with esbuild — a good candidate for controlled adoption this quarter. (bun.com)

Source

• Bun v1.3.6 release notes (Bun blog). (bun.com)

Source

• Source