सामग्री पर जाएं
27 मिनट पढ़ने का समय

Production में Bun: क्या काम करता है, क्या नहीं, और क्या Surprise किया

Bun as runtime, package manager, bundler, और test runner। Real benchmarks, Node.js compatibility gaps, migration patterns, और मैं आज production में Bun कहां use कर रहा हूं।

bunnode.jsjavascriptruntimeperformance
साझा करें:X / TwitterLinkedIn

हर कुछ सालों में, JavaScript ecosystem को new runtime मिलता है और discourse एक predictable arc follow करता है। Hype। Benchmarks। "X is dead।" Reality check। और फिर उन actual use cases में settle हो जाना जहां new tool genuinely shine करता है।

Bun अभी उसी arc के बीच में है। और ज़्यादातर challengers से unlike, यह टिक रहा है। इसलिए नहीं कि यह "faster" है (हालांकि अक्सर है), बल्कि इसलिए कि यह genuinely अलग problem solve कर रहा है: JavaScript toolchain में बहुत ज़्यादा moving parts हैं, और Bun उन्हें एक में collapse करता है।

मैं एक साल से ज़्यादा से Bun अलग-अलग capacities में use कर रहा हूं। कुछ production में। कुछ उन tools को replace करते हुए जो मुझे लगता था कभी replace नहीं होंगे। यह post एक honest accounting है कि क्या काम करता है, क्या नहीं, और कहां gaps अभी भी matter करते हैं।

Bun Actually क्या है#

पहली misconception clear करनी होगी: Bun "faster Node.js" नहीं है। यह framing इसे undersell करता है।

Bun एक binary में चार tools है:

  1. JavaScript/TypeScript runtime — आपका code run करता है, Node.js या Deno की तरह
  2. Package manager — npm, yarn, या pnpm replace करता है
  3. Bundler — certain use cases के लिए esbuild, webpack, या Rollup replace करता है
  4. Test runner — ज़्यादातर test suites के लिए Jest या Vitest replace करता है

Node.js से key architectural difference engine है। Node.js V8 (Chrome का engine) use करता है। Bun JavaScriptCore (Safari का engine) use करता है। दोनों mature, production-grade engines हैं, लेकिन अलग tradeoffs बनाते हैं। JavaScriptCore generally faster startup times और lower memory overhead देता है। V8 generally long-running computations के लिए better peak throughput देता है। Practice में, ये differences ज़्यादातर workloads के लिए आप सोचते हैं उससे छोटे हैं।

दूसरा major differentiator: Bun Zig में लिखा है, एक systems programming language जो roughly C जैसे ही level पर बैठती है लेकिन better memory safety guarantees के साथ। इसीलिए Bun performance के साथ इतना aggressive हो सकता है — Zig उस तरह का low-level control देता है जो C provide करता है बिना C की footgun density के।

bash
# Check your Bun version
bun --version
 
# Run a TypeScript file directly — no tsconfig, no compilation step
bun run server.ts
 
# Install packages
bun install
 
# Run tests
bun test
 
# Bundle for production
bun build ./src/index.ts --outdir ./dist

एक binary node + npm + esbuild + vitest का काम कर रही है। पसंद करो या न करो, complexity में यह compelling reduction है।

Speed Claims — Honest Benchmarks#

इस बारे में direct रहूंगा: Bun के marketing benchmarks cherry-picked हैं। Fraudulent नहीं — cherry-picked। ये वो scenarios दिखाते हैं जहां Bun best perform करता है, जो exactly वही है जो marketing material से expect करोगे। Problem यह है कि लोग इन benchmarks से extrapolate करके claim करते हैं कि Bun हर चीज़ में "25x faster" है, जो बिल्कुल नहीं है।

यहां Bun genuinely, meaningfully faster है:

Startup Time#

यह Bun का सबसे बड़ा genuine advantage है और close भी नहीं है।

bash
# Measuring startup time — run each 100 times
hyperfine --warmup 5 'node -e "console.log(1)"' 'bun -e "console.log(1)"'
 
# Typical results:
# node:  ~40ms
# bun:   ~6ms

यह startup time में roughly 6-7x difference है। Scripts, CLI tools, और serverless functions के लिए जहां cold start matter करता है, यह significant है। Long-running server process के लिए जो एक बार start होता है और weeks तक run करता है, यह irrelevant है।

Package Installation#

यह दूसरा area है जहां Bun competition को embarrass करता है।

bash
# Clean install benchmark — delete node_modules and lockfile first
rm -rf node_modules bun.lockb package-lock.json
 
# Time npm
time npm install
# Real: ~18.4s (typical medium-sized project)
 
# Time bun
time bun install
# Real: ~2.1s

यह 8-9x difference है, और consistent है। कारण primarily हैं:

  1. Binary lockfile — bun.lockb binary format है, JSON नहीं। Read और write करने में faster।
  2. Global cache — Bun global module cache maintain करता है ताकि projects में reinstalls downloaded packages share करें।
  3. Zig की I/O — Package manager खुद Zig में लिखा है, JavaScript में नहीं। File I/O operations metal के ज़्यादा करीब हैं।
  4. Symlink strategy — Bun files copy करने की जगह global cache से hardlinks use करता है।

HTTP Server Throughput#

Bun का built-in HTTP server fast है, लेकिन comparisons को context चाहिए।

bash
# Quick and dirty benchmark with bombardier
# Testing a simple "Hello World" response
 
# Bun server
bombardier -c 100 -d 10s http://localhost:3000
# Requests/sec: ~105,000
 
# Node.js (native http module)
bombardier -c 100 -d 10s http://localhost:3001
# Requests/sec: ~48,000
 
# Node.js (Express)
bombardier -c 100 -d 10s http://localhost:3002
# Requests/sec: ~15,000

Bun vs. raw Node.js: trivial responses के लिए roughly 2x। Bun vs. Express: roughly 7x, लेकिन यह unfair है क्योंकि Express middleware overhead add करता है। जैसे ही real logic add करते हैं — database queries, authentication, actual data की JSON serialization — gap dramatically narrow हो जाता है।

जहां Difference Negligible है#

CPU-bound computation:

typescript
// fibonacci.ts — this is engine-bound, not runtime-bound
function fib(n: number): number {
  if (n <= 1) return n;
  return fib(n - 1) + fib(n - 2);
}
 
const start = performance.now();
console.log(fib(42));
console.log(`${(performance.now() - start).toFixed(0)}ms`);
bash
bun run fibonacci.ts   # ~1650ms
node fibonacci.ts      # ~1580ms

Node.js (V8) actually यहां slightly जीतता है। V8 का JIT compiler hot loops पर ज़्यादा aggressive है। CPU-bound work के लिए, engine differences बराबर हैं — कभी V8 जीतता है, कभी JSC, और differences noise के अंदर हैं।

अपने Benchmarks खुद कैसे Run करें#

किसी के benchmarks पर trust मत करो, मेरे भी। अपनी specific workload के लिए जो matter करता है वो measure करने का तरीका:

bash
# Install hyperfine for proper benchmarking
brew install hyperfine  # macOS
# or: cargo install hyperfine
 
# Benchmark startup + execution of your actual app
hyperfine --warmup 3 \
  'node dist/server.js' \
  'bun src/server.ts' \
  --prepare 'sleep 0.1'
 
# For HTTP servers, use bombardier or wrk
# Important: test with realistic payloads, not "Hello World"
bombardier -c 50 -d 30s -l http://localhost:3000/api/users
 
# Memory comparison
/usr/bin/time -v node server.js  # Linux
/usr/bin/time -l bun server.ts   # macOS

Rule of thumb: अगर bottleneck I/O है (file system, network, database), Bun का advantage modest है। अगर bottleneck startup time या toolchain speed है, Bun बड़ा जीतता है। अगर bottleneck raw computation है, toss-up है।

Package Manager के रूप में Bun#

यहां मैंने पूरी तरह switch कर लिया है। उन projects पर भी जहां production में Node.js run करता हूं, local development और CI के लिए bun install use करता हूं। बस faster है, और compatibility excellent है।

Basics#

bash
# Install all dependencies from package.json
bun install
 
# Add a dependency
bun add express
 
# Add a dev dependency
bun add -d vitest
 
# Remove a dependency
bun remove express
 
# Update a dependency
bun update express
 
# Install a specific version
bun add express@4.18.2

अगर npm या yarn use किया है, तो यह पूरी तरह familiar है। Flags थोड़े अलग हैं (--save-dev की जगह -d), लेकिन mental model identical है।

Lockfile की Situation#

Bun bun.lockb use करता है, binary lockfile। यह इसकी superpower भी है और सबसे बड़ा friction point भी।

अच्छी बात: Read और write करना dramatically faster है। Binary format मतलब Bun lockfile microseconds में parse करता है, package-lock.json parse करने में npm जो hundreds of milliseconds लगाता है उसकी जगह।

बुरी बात: Diff में review नहीं कर सकते। अगर team पर हैं और कोई dependency update करता है, PR में lockfile diff देखकर नहीं बता सकते क्या बदला। यह speed advocates जितना admit करना चाहते हैं उससे ज़्यादा matter करता है।

bash
# You can dump the lockfile to human-readable format
bun bun.lockb > lockfile-dump.txt
 
# Or use the built-in text output
bun install --yarn
# This generates a yarn.lock alongside bun.lockb

मेरा approach: bun.lockb repo में commit करता हूं और readable fallback के रूप में yarn.lock या package-lock.json भी generate करता हूं। Belt and suspenders।

Workspace Support#

Bun npm/yarn-style workspaces support करता है:

json
{
  "name": "my-monorepo",
  "workspaces": [
    "packages/*",
    "apps/*"
  ]
}
bash
# Install dependencies for all workspaces
bun install
 
# Run a script in a specific workspace
bun run --filter packages/shared build
 
# Add a dependency to a specific workspace
bun add react --filter apps/web

Workspace support solid है और significantly improve हुआ है। pnpm की तुलना में main gap यह है कि Bun की workspace dependency resolution कम strict है — pnpm की strictness monorepos के लिए feature है क्योंकि यह phantom dependencies catch करती है।

Existing Projects के साथ Compatibility#

लगभग किसी भी existing Node.js project में bun install drop कर सकते हैं। यह package.json पढ़ता है, registry configuration के लिए .npmrc respect करता है, और peerDependencies correctly handle करता है। Transition typically है:

bash
# Step 1: Delete existing lockfile and node_modules
rm -rf node_modules package-lock.json yarn.lock pnpm-lock.yaml
 
# Step 2: Install with Bun
bun install
 
# Step 3: Verify your app still works
bun run dev
# or: node dist/server.js  (Bun package manager, Node runtime)

मैंने यह dozen projects पर किया है और package manager से zero issues आए। सिर्फ gotcha यह है कि अगर CI pipeline specifically package-lock.json ढूंढती है — तो bun.lockb handle करने के लिए update करना पड़ेगा।

Node.js Compatibility#

यह वो section है जहां मुझे सबसे ज़्यादा careful रहना होगा, क्योंकि situation हर month बदलती है। Early 2026 तक, honest picture यह है।

क्या काम करता है#

ज़्यादातर npm packages बिना modification के काम करते हैं। Bun ज़्यादातर Node.js built-in modules implement करता है:

typescript
// These all work as expected in Bun
import fs from "node:fs";
import path from "node:path";
import crypto from "node:crypto";
import { Buffer } from "node:buffer";
import { EventEmitter } from "node:events";
import { Readable, Writable } from "node:stream";
import http from "node:http";
import https from "node:https";
import { URL, URLSearchParams } from "node:url";
import os from "node:os";
import child_process from "node:child_process";

CommonJS और ESM दोनों काम करते हैं। require() और import coexist कर सकते हैं। TypeScript बिना किसी compilation step के run होता है — Bun parse time पर types strip करता है।

Frameworks जो काम करते हैं:

  • Express — काम करता है, middleware ecosystem सहित
  • Fastify — काम करता है
  • Hono — काम करता है (और Bun के साथ excellent है)
  • Next.js — caveats के साथ काम करता है (इसके बारे में नीचे और)
  • Prisma — काम करता है
  • Drizzle ORM — काम करता है
  • Socket.io — काम करता है

क्या नहीं (या Issues हैं)#

Gaps कुछ categories में आते हैं:

Native addons (node-gyp): अगर कोई package node-gyp से compiled C++ addons use करता है, तो Bun में काम नहीं कर सकता। Bun का अपना FFI system है और बहुत सारे native modules support करता है, लेकिन coverage 100% नहीं। जैसे, bcrypt (native वाला) में issues रहे हैं — bcryptjs use करें।

bash
# Check if a package uses native addons
ls node_modules/your-package/binding.gyp  # If this exists, it's native

Specific Node.js internals: कुछ packages Node.js internals जैसे process.binding() में reach करते हैं या V8-specific APIs use करते हैं। ये Bun में काम नहीं करेंगे क्योंकि यह JavaScriptCore पर run होता है।

typescript
// This will NOT work in Bun — V8-specific
const v8 = require("v8");
v8.serialize({ data: "test" });
 
// This WILL work — use Bun's equivalent or a cross-runtime approach
const encoded = new TextEncoder().encode(JSON.stringify({ data: "test" }));

Worker threads: Bun Web Workers और node:worker_threads support करता है, लेकिन edge cases हैं। कुछ advanced usage patterns — खासकर SharedArrayBuffer और Atomics के around — अलग behave कर सकते हैं।

vm module: node:vm partial support है। अगर आपका code या dependency vm.createContext() extensively use करता है (कुछ template engines करते हैं), तो thoroughly test करें।

Compatibility Tracker#

Bun official compatibility tracker maintain करता है। Project के लिए Bun commit करने से पहले check करें:

bash
# Run Bun's built-in compatibility check on your project
bun --bun node_modules/.bin/your-tool
 
# The --bun flag forces Bun's runtime even for node_modules scripts

मेरी recommendation: compatibility assume मत करो। Decide करने से पहले Bun के under अपना test suite run करो। पांच minute लगते हैं और debugging के घंटे बचाता है।

bash
# Quick compatibility check — run your full test suite under Bun
bun test  # If you use bun test runner
# or
bun run vitest  # If you use vitest

Bun की Built-in APIs#

यहां Bun interesting होता है। सिर्फ Node.js APIs re-implement करने की जगह, Bun अपनी APIs provide करता है जो simpler और faster होने के लिए designed हैं।

Bun.serve() — Built-in HTTP Server#

यह वो API है जो मैं सबसे ज़्यादा use करता हूं। Clean, fast, और WebSocket support built right in है।

typescript
const server = Bun.serve({
  port: 3000,
  fetch(req) {
    const url = new URL(req.url);
 
    if (url.pathname === "/") {
      return new Response("Hello from Bun!", {
        headers: { "Content-Type": "text/plain" },
      });
    }
 
    if (url.pathname === "/api/users") {
      const users = [
        { id: 1, name: "Alice" },
        { id: 2, name: "Bob" },
      ];
      return Response.json(users);
    }
 
    return new Response("Not Found", { status: 404 });
  },
});
 
console.log(`Server running at http://localhost:${server.port}`);

कुछ चीज़ें notice करें:

  1. Web-standard Request/Response — कोई proprietary API नहीं। fetch handler standard Request receive करता है और standard Response return करता है। अगर Cloudflare Worker लिखा है, तो यह identical feel होगा।
  2. Response.json() — built-in JSON response helper।
  3. Import की ज़रूरत नहीं — Bun.serve global है। require("http") नहीं चाहिए।

Routing, JSON body parsing, और error handling के साथ ज़्यादा realistic example:

typescript
import { Database } from "bun:sqlite";
 
const db = new Database("app.db");
db.run(`
  CREATE TABLE IF NOT EXISTS todos (
    id INTEGER PRIMARY KEY AUTOINCREMENT,
    title TEXT NOT NULL,
    completed INTEGER DEFAULT 0,
    created_at TEXT DEFAULT (datetime('now'))
  )
`);
 
const server = Bun.serve({
  port: process.env.PORT || 3000,
 
  async fetch(req) {
    const url = new URL(req.url);
    const method = req.method;
 
    try {
      // GET /api/todos
      if (url.pathname === "/api/todos" && method === "GET") {
        const todos = db.query("SELECT * FROM todos ORDER BY created_at DESC").all();
        return Response.json(todos);
      }
 
      // POST /api/todos
      if (url.pathname === "/api/todos" && method === "POST") {
        const body = await req.json();
 
        if (!body.title || typeof body.title !== "string") {
          return Response.json({ error: "Title is required" }, { status: 400 });
        }
 
        const stmt = db.prepare("INSERT INTO todos (title) VALUES (?) RETURNING *");
        const todo = stmt.get(body.title);
        return Response.json(todo, { status: 201 });
      }
 
      // DELETE /api/todos/:id
      const deleteMatch = url.pathname.match(/^\/api\/todos\/(\d+)$/);
      if (deleteMatch && method === "DELETE") {
        const id = parseInt(deleteMatch[1], 10);
        db.run("DELETE FROM todos WHERE id = ?", [id]);
        return new Response(null, { status: 204 });
      }
 
      return Response.json({ error: "Not found" }, { status: 404 });
    } catch (error) {
      console.error("Request error:", error);
      return Response.json({ error: "Internal server error" }, { status: 500 });
    }
  },
});
 
console.log(`Server running on port ${server.port}`);

करीब 50 lines में SQLite के साथ full CRUD API। कोई Express, ORM, या middleware chain नहीं। छोटी APIs और internal tools के लिए, अब यह मेरा go-to setup है।

Bun.file() और Bun.write() — File I/O#

fs.readFile() की तुलना में Bun की file API refreshingly simple है:

typescript
// Reading files
const file = Bun.file("./config.json");
const text = await file.text();       // Read as string
const json = await file.json();       // Parse as JSON directly
const bytes = await file.arrayBuffer(); // Read as ArrayBuffer
const stream = file.stream();          // Read as ReadableStream
 
// File metadata
console.log(file.size);  // Size in bytes
console.log(file.type);  // MIME type (e.g., "application/json")
 
// Writing files
await Bun.write("./output.txt", "Hello, World!");
await Bun.write("./data.json", JSON.stringify({ key: "value" }));
await Bun.write("./copy.png", Bun.file("./original.png"));
 
// Write a Response body to a file
const response = await fetch("https://example.com/data.json");
await Bun.write("./downloaded.json", response);

Bun.file() API lazy है — जब तक .text(), .json() आदि call नहीं करते तब तक file read नहीं करता। मतलब बिना I/O costs के Bun.file() references pass कर सकते हैं जब तक actually data चाहिए न हो।

Built-in WebSocket Support#

WebSockets Bun.serve() में first-class हैं:

typescript
const server = Bun.serve({
  port: 3000,
 
  fetch(req, server) {
    const url = new URL(req.url);
 
    if (url.pathname === "/ws") {
      const upgraded = server.upgrade(req, {
        data: {
          userId: url.searchParams.get("userId"),
          joinedAt: Date.now(),
        },
      });
 
      if (!upgraded) {
        return new Response("WebSocket upgrade failed", { status: 400 });
      }
      return undefined;
    }
 
    return new Response("Use /ws for WebSocket connections");
  },
 
  websocket: {
    open(ws) {
      console.log(`Client connected: ${ws.data.userId}`);
      ws.subscribe("chat");
    },
 
    message(ws, message) {
      // Broadcast to all subscribers
      server.publish("chat", `${ws.data.userId}: ${message}`);
    },
 
    close(ws) {
      console.log(`Client disconnected: ${ws.data.userId}`);
      ws.unsubscribe("chat");
    },
  },
});

server.publish() और ws.subscribe() pattern built-in pub/sub है। कोई Redis नहीं, कोई separate WebSocket library नहीं। Simple real-time features के लिए, यह incredibly convenient है।

bun:sqlite के साथ Built-in SQLite#

इसने मुझे सबसे ज़्यादा surprise किया। Bun के runtime में SQLite built right in है:

typescript
import { Database } from "bun:sqlite";
 
// Open or create a database
const db = new Database("myapp.db");
 
// WAL mode for better concurrent read performance
db.exec("PRAGMA journal_mode = WAL");
 
// Create tables
db.run(`
  CREATE TABLE IF NOT EXISTS users (
    id INTEGER PRIMARY KEY AUTOINCREMENT,
    email TEXT UNIQUE NOT NULL,
    name TEXT NOT NULL,
    created_at TEXT DEFAULT (datetime('now'))
  )
`);
 
// Prepared statements (reusable, faster for repeated queries)
const insertUser = db.prepare(
  "INSERT INTO users (email, name) VALUES ($email, $name) RETURNING *"
);
 
const findByEmail = db.prepare(
  "SELECT * FROM users WHERE email = $email"
);
 
// Usage
const user = insertUser.get({
  $email: "alice@example.com",
  $name: "Alice",
});
console.log(user); // { id: 1, email: "alice@example.com", name: "Alice", ... }
 
// Transactions
const insertMany = db.transaction((users: { email: string; name: string }[]) => {
  for (const user of users) {
    insertUser.run({ $email: user.email, $name: user.name });
  }
  return users.length;
});
 
const count = insertMany([
  { email: "bob@example.com", name: "Bob" },
  { email: "carol@example.com", name: "Carol" },
]);
console.log(`Inserted ${count} users`);

यह synchronous SQLite है C library की performance के साथ (क्योंकि यह एक है — Bun libsqlite3 directly embed करता है)। CLI tools, local-first apps, और छोटी services के लिए, built-in SQLite मतलब data layer के लिए zero external dependencies।

Bun Test Runner#

bun test ज़्यादातर cases में Jest का drop-in replacement है। Same describe/it/expect API use करता है और ज़्यादातर Jest matchers support करता है।

Basic Usage#

typescript
// math.test.ts
import { describe, it, expect } from "bun:test";
 
describe("math utilities", () => {
  it("adds numbers correctly", () => {
    expect(1 + 2).toBe(3);
  });
 
  it("handles floating point", () => {
    expect(0.1 + 0.2).toBeCloseTo(0.3);
  });
});
bash
# Run all tests
bun test
 
# Run specific file
bun test math.test.ts
 
# Run tests matching a pattern
bun test --test-name-pattern "adds numbers"
 
# Watch mode
bun test --watch
 
# Coverage
bun test --coverage

Mocking#

Bun Jest-compatible mocking support करता है:

typescript
import { describe, it, expect, mock, spyOn } from "bun:test";
import { fetchUsers } from "./api";
 
// Mock a module
mock.module("./database", () => ({
  query: mock(() => [{ id: 1, name: "Alice" }]),
}));
 
describe("fetchUsers", () => {
  it("returns users from database", async () => {
    const users = await fetchUsers();
    expect(users).toHaveLength(1);
    expect(users[0].name).toBe("Alice");
  });
});
 
// Spy on an object method
describe("console", () => {
  it("tracks console.log calls", () => {
    const logSpy = spyOn(console, "log");
    console.log("test message");
    expect(logSpy).toHaveBeenCalledWith("test message");
    logSpy.mockRestore();
  });
});

Bun Test vs. Vitest — मेरी Honest Comparison#

मैं इस project (और अपने ज़्यादातर projects) के लिए Vitest use करता हूं। पूरी तरह switch क्यों नहीं किया यहां बताता हूं:

जहां bun test जीतता है:

  • Startup speed। bun test tests execute करना शुरू करता है Vitest के config load होने से पहले।
  • Zero config। Basic setups के लिए vitest.config.ts की ज़रूरत नहीं।
  • Built-in TypeScript। कोई transformation step नहीं।

जहां Vitest अभी भी जीतता है:

  • Ecosystem: Vitest के पास ज़्यादा plugins, better IDE integration, और larger community है।
  • Configuration: Vitest का config system ज़्यादा flexible है। Custom reporters, complex setup files, multiple test environments।
  • Browser mode: Vitest tests actual browser में run कर सकता है। Bun नहीं कर सकता।
  • Compatibility: कुछ testing libraries (Testing Library, MSW) Vitest/Jest के साथ ज़्यादा thoroughly test की गई हैं।
  • Snapshot testing: दोनों support करते हैं, लेकिन Vitest का implementation better diff output के साथ ज़्यादा mature है।

New project जिसकी simple testing needs हैं, उसके लिए bun test use करूंगा। Established project जिसमें Testing Library, MSW, और complex mocking है, उसके लिए Vitest रखूंगा।

Bun Bundler#

bun build fast JavaScript/TypeScript bundler है। Webpack replacement नहीं — esbuild category में ज़्यादा है: fast, opinionated, और common cases पर focused।

Basic Bundling#

bash
# Bundle a single entry point
bun build ./src/index.ts --outdir ./dist
 
# Bundle for different targets
bun build ./src/index.ts --outdir ./dist --target browser
bun build ./src/index.ts --outdir ./dist --target bun
bun build ./src/index.ts --outdir ./dist --target node
 
# Minify
bun build ./src/index.ts --outdir ./dist --minify
 
# Generate sourcemaps
bun build ./src/index.ts --outdir ./dist --sourcemap external

Programmatic API#

typescript
const result = await Bun.build({
  entrypoints: ["./src/index.ts", "./src/worker.ts"],
  outdir: "./dist",
  target: "browser",
  minify: {
    whitespace: true,
    identifiers: true,
    syntax: true,
  },
  splitting: true,    // Code splitting
  sourcemap: "external",
  external: ["react", "react-dom"],  // Don't bundle these
  naming: "[dir]/[name]-[hash].[ext]",
  define: {
    "process.env.NODE_ENV": JSON.stringify("production"),
  },
});
 
if (!result.success) {
  console.error("Build failed:");
  for (const log of result.logs) {
    console.error(log);
  }
  process.exit(1);
}
 
for (const output of result.outputs) {
  console.log(`${output.path} — ${output.size} bytes`);
}

Tree-Shaking#

Bun ESM के लिए tree-shaking support करता है:

typescript
// utils.ts
export function used() {
  return "I'll be in the bundle";
}
 
export function unused() {
  return "I'll be tree-shaken away";
}
 
// index.ts
import { used } from "./utils";
console.log(used());
bash
bun build ./src/index.ts --outdir ./dist --minify
# The `unused` function won't appear in the output

जहां Bun Build कम पड़ता है#

  • CSS bundling नहीं — CSS के लिए separate tool चाहिए (PostCSS, Lightning CSS, Tailwind CLI)।
  • HTML generation नहीं — JavaScript/TypeScript bundle करता है, full web apps नहीं।
  • Plugin ecosystem — esbuild का बहुत बड़ा plugin ecosystem है। Bun की plugin API compatible है लेकिन community छोटी है।
  • Advanced code splitting — Webpack और Rollup अभी भी ज़्यादा sophisticated chunk strategies offer करते हैं।

Library build करने या simple web app का JS bundle बनाने के लिए, bun build excellent है। Complex app builds जिनमें CSS modules, image optimization, और custom chunk strategies हैं, उनके लिए अभी भी full bundler चाहिए।

Bun Macros#

एक genuinely unique feature: macros के ज़रिए compile-time code execution।

typescript
// build-info.ts — this file runs at BUILD TIME, not runtime
export function getBuildInfo() {
  return {
    builtAt: new Date().toISOString(),
    gitSha: require("child_process")
      .execSync("git rev-parse --short HEAD")
      .toString()
      .trim(),
    nodeVersion: process.version,
  };
}
typescript
// app.ts
import { getBuildInfo } from "./build-info" with { type: "macro" };
 
// getBuildInfo() executes at bundle time
// The result is inlined as a static value
const info = getBuildInfo();
console.log(`Built at ${info.builtAt}, commit ${info.gitSha}`);

Bundling के बाद, getBuildInfo() literal object से replace हो जाता है — runtime पर कोई function call नहीं, child_process का import नहीं। Code build के दौरान run हुआ और result inline हो गया। Build metadata, feature flags, या environment-specific configuration embed करने के लिए powerful है।

Next.js के साथ Bun#

यह वो question है जो मुझसे सबसे ज़्यादा पूछा जाता है, तो बहुत specific रहूंगा।

आज क्या काम करता है#

Next.js के लिए package manager के रूप में Bun — perfectly काम करता है:

bash
# Use Bun to install dependencies, then use Node.js to run Next.js
bun install
bun run dev    # This actually runs the "dev" script via Node.js by default
bun run build
bun run start

मैं हर Next.js project के लिए यही करता हूं। bun run <script> command package.json का scripts section पढ़ता है और execute करता है। Default में, actual execution के लिए system का Node.js use करता है। आपको Bun की fast package installation मिलती है बिना runtime change किए।

Next.js development के लिए Bun runtime:

bash
# Force Next.js to run under Bun's runtime
bun --bun run dev

Development में ज़्यादातर cases में काम करता है। --bun flag Bun को Node.js पर delegate करने की जगह अपना runtime use करने बोलता है। Hot module replacement काम करता है। API routes काम करते हैं। Server components काम करते हैं।

क्या अभी Experimental है#

Next.js production builds के लिए Bun runtime:

bash
# Build with Bun runtime
bun --bun run build
 
# Start production server with Bun runtime
bun --bun run start

बहुत सारे projects के लिए काम करता है लेकिन edge cases मिले हैं:

  1. कुछ middleware behaviors differ होते हैं — अगर Next.js middleware use करते हैं जो Node.js-specific APIs पर depend करता है, compatibility issues हो सकते हैं।
  2. Image optimization — Next.js की image optimization pipeline sharp use करती है, जो native addon है। Bun के साथ काम करता है, लेकिन occasional issues देखे हैं।
  3. ISR (Incremental Static Regeneration) — काम करता है, लेकिन production में Bun के under stress-test नहीं किया।

Next.js के लिए मेरी Recommendation#

Bun package manager के रूप में use करो। Node.js runtime के रूप में use करो। bun install के speed benefits मिलते हैं बिना किसी compatibility risk के।

json
{
  "scripts": {
    "dev": "next dev --turbopack",
    "build": "next build",
    "start": "next start"
  }
}
bash
# Daily workflow
bun install      # Fast package installation
bun run dev      # Runs "next dev" via Node.js
bun run build    # Runs "next build" via Node.js

जब Bun की Node.js compatibility Next.js के internal usage के लिए 100% पहुंच जाएगी (close है, लेकिन अभी नहीं), तब switch करूंगा। तब तक, अकेले package manager इतना time बचाता है कि install justify करता है।

Bun के साथ Docker#

Official Bun Docker image well-maintained और production-ready है।

Basic Dockerfile#

dockerfile
FROM oven/bun:1 AS base
WORKDIR /app
 
# Install dependencies
FROM base AS deps
COPY package.json bun.lockb ./
RUN bun install --frozen-lockfile --production
 
# Build (if needed)
FROM base AS build
COPY package.json bun.lockb ./
RUN bun install --frozen-lockfile
COPY . .
RUN bun run build
 
# Production
FROM base AS production
WORKDIR /app
 
# Don't run as root
RUN addgroup --system --gid 1001 appgroup && \
    adduser --system --uid 1001 appuser
USER appuser
 
COPY --from=deps /app/node_modules ./node_modules
COPY --from=build /app/dist ./dist
COPY --from=build /app/package.json ./
 
EXPOSE 3000
CMD ["bun", "run", "dist/server.js"]

Minimal Image के लिए Multi-Stage Build#

dockerfile
# Build stage: full Bun image with all dependencies
FROM oven/bun:1 AS builder
WORKDIR /app
COPY package.json bun.lockb ./
RUN bun install --frozen-lockfile
COPY . .
RUN bun build ./src/index.ts --target bun --outdir ./dist --minify
 
# Runtime stage: smaller base image
FROM oven/bun:1-slim AS runtime
WORKDIR /app
 
RUN addgroup --system --gid 1001 appgroup && \
    adduser --system --uid 1001 appuser
USER appuser
 
COPY --from=builder /app/dist ./dist
 
EXPOSE 3000
CMD ["bun", "run", "dist/index.js"]

Single Binary में Compile करना#

Deployment के लिए Bun के killer features में से एक:

bash
# Compile your app into a single executable
bun build --compile ./src/server.ts --outfile server
 
# The output is a standalone binary — no Bun or Node.js needed to run it
./server
dockerfile
# Ultra-minimal Docker image using compiled binary
FROM oven/bun:1 AS builder
WORKDIR /app
COPY package.json bun.lockb ./
RUN bun install --frozen-lockfile
COPY . .
RUN bun build --compile ./src/server.ts --outfile server
 
# Final image — just the binary
FROM debian:bookworm-slim
WORKDIR /app
 
RUN addgroup --system --gid 1001 appgroup && \
    adduser --system --uid 1001 appuser
USER appuser
 
COPY --from=builder /app/server ./server
 
EXPOSE 3000
CMD ["./server"]

Compiled binary typically 50-90 MB होती है (Bun runtime bundle होता है)। Go binary से बड़ी लेकिन full Node.js installation plus node_modules से बहुत छोटी। Containerized deployments के लिए, self-contained nature significant simplification है।

Size Comparison#

bash
# Node.js image
docker images | grep node
# node:20-slim    ~180MB
 
# Bun image
docker images | grep bun
# oven/bun:1-slim  ~130MB
 
# Compiled binary on debian:bookworm-slim
# ~80MB base + ~70MB binary = ~150MB total
 
# vs. Alpine with Node.js
# node:20-alpine   ~130MB + node_modules

Binary approach node_modules को final image से पूरी तरह eliminate करता है। Production में npm install नहीं। Hundreds of packages से supply chain surface area नहीं। बस एक file।

Migration Patterns#

अगर Bun पर move करने पर विचार कर रहे हैं, तो यह incremental path recommend करता हूं:

Phase 1: सिर्फ Package Manager (Zero Risk)#

bash
# Replace npm/yarn/pnpm with bun install
# Change your CI pipeline:
# Before:
npm ci
 
# After:
bun install --frozen-lockfile

कोई code changes नहीं। कोई runtime changes नहीं। बस faster installs। अगर कुछ टूटता है (नहीं टूटेगा), bun.lockb delete करो और npm install run करो।

Phase 2: Scripts और Tooling#

bash
# Use bun to run development scripts
bun run dev
bun run lint
bun run format
 
# Use bun for one-off scripts
bun run scripts/seed-database.ts
bun run scripts/migrate.ts

अभी भी actual application के लिए Node.js runtime use कर रहे हैं। लेकिन scripts Bun के faster startup और native TypeScript support से benefit करती हैं।

Phase 3: Test Runner (Medium Risk)#

bash
# Replace vitest/jest with bun test for simple test suites
bun test
 
# Keep vitest for complex test setups
# (Testing Library, MSW, custom environments)

bun test के under full test suite run करो। अगर सब pass होता है, एक devDependency eliminate हो गई। अगर कुछ tests compatibility से fail होते हैं, उनके लिए Vitest रखो और बाकी के लिए bun test use करो।

Phase 4: New Services के लिए Runtime (Calculated Risk)#

typescript
// New microservices or APIs — start with Bun from day one
Bun.serve({
  port: 3000,
  fetch(req) {
    // Your new service here
  },
});

Existing Node.js services को Bun runtime पर migrate मत करो। बल्कि, new services शुरू से Bun के साथ लिखो। Blast radius limited रहता है।

Phase 5: Runtime Migration (Advanced)#

bash
# Only after thorough testing:
# Replace node with bun for existing services
# Before:
node dist/server.js
 
# After:
bun dist/server.js

मैं यह सिर्फ excellent test coverage वाली services के लिए recommend करता हूं। Production switch करने से पहले Bun के under load tests run करो।

Environment Variables और Configuration#

Bun .env files automatically handle करता है — dotenv package की ज़रूरत नहीं:

bash
# .env
DATABASE_URL=postgresql://localhost:5432/myapp
API_KEY=sk-test-12345
PORT=3000
typescript
// These are available without any import
console.log(process.env.DATABASE_URL);
console.log(process.env.API_KEY);
console.log(Bun.env.PORT); // Bun-specific alternative

Bun .env, .env.local, .env.production आदि automatically load करता है, Next.js जैसी convention follow करते हुए। package.json में एक dependency कम।

Error Handling और Debugging#

Bun का error output significantly improve हुआ है, लेकिन कुछ cases में अभी भी Node.js जितना polished नहीं:

bash
# Bun's debugger — works with VS Code
bun --inspect run server.ts
 
# Bun's inspect-brk — pause on first line
bun --inspect-brk run server.ts

VS Code के लिए, .vscode/launch.json में यह add करें:

json
{
  "version": "0.2.0",
  "configurations": [
    {
      "type": "bun",
      "request": "launch",
      "name": "Debug Bun",
      "program": "${workspaceFolder}/src/server.ts",
      "cwd": "${workspaceFolder}",
      "stopOnEntry": false,
      "watchMode": false
    }
  ]
}

Bun में stack traces generally accurate हैं और TypeScript के लिए source maps include करते हैं। Main debugging gap यह है कि कुछ Node.js-specific debugging tools (जैसे ndb या clinic.js) Bun के साथ काम नहीं करते।

Security Considerations#

Production के लिए Bun evaluate कर रहे हैं तो कुछ चीज़ें सोचने वाली:

Maturity: Node.js 15+ साल से production में है। HTTP parsing, TLS handling, और stream processing का हर edge case find और fix हो चुका है। Bun younger है। Well-tested है, लेकिन undiscovered bugs का surface area बड़ा है।

Security patches: Bun team frequently updates ship करती है, लेकिन Node.js security team का formal CVE process, coordinated disclosure, और longer track record है। Security-critical applications के लिए, यह matter करता है।

Supply chain: Bun के built-in features (SQLite, HTTP server, WebSockets) मतलब कम npm dependencies। कम dependencies मतलब छोटा supply chain attack surface। यह genuine security advantage है।

bash
# Compare dependency counts
# A typical Express + SQLite + WebSocket project:
npm ls --all | wc -l
# ~340 packages
 
# The same functionality with Bun built-ins:
bun pm ls --all | wc -l
# ~12 packages (just your application code)

Production workload को trust करने वाले packages की संख्या में meaningful reduction।

Performance Tuning#

कुछ Bun-specific performance tips:

typescript
// Use Bun.serve() options for production tuning
Bun.serve({
  port: 3000,
 
  // Increase max request body size (default is 128MB)
  maxRequestBodySize: 1024 * 1024 * 50, // 50MB
 
  // Enable development mode for better error pages
  development: process.env.NODE_ENV !== "production",
 
  // Reuse port (useful for zero-downtime restarts)
  reusePort: true,
 
  fetch(req) {
    return new Response("OK");
  },
});
typescript
// Use Bun.Transpiler for runtime code transformation
const transpiler = new Bun.Transpiler({
  loader: "tsx",
  target: "browser",
});
 
const code = transpiler.transformSync(`
  const App: React.FC = () => <div>Hello</div>;
  export default App;
`);
bash
# Bun's memory usage flags
bun --smol run server.ts  # Reduce memory footprint (slightly slower)
 
# Set max heap size
BUN_JSC_forceRAMSize=512000000 bun run server.ts  # ~512MB limit

Common Gotchas#

एक साल Bun use करने के बाद, ये चीज़ें trip कर चुकी हैं:

1. Global Fetch Behavior अलग है#

typescript
// Node.js 18+ fetch and Bun's fetch are slightly different
// in how they handle certain headers and redirects
 
// Bun follows redirects by default (like browsers)
// Node.js fetch also follows redirects, but the behavior
// with certain status codes (303, 307, 308) can differ
 
const response = await fetch("https://api.example.com/data", {
  redirect: "manual", // Be explicit about redirect handling
});

2. Process Exit Behavior#

typescript
// Bun exits when the event loop is empty
// Node.js sometimes keeps running due to lingering handles
 
// If your Bun script exits unexpectedly, something isn't
// keeping the event loop alive
 
// This will exit immediately in Bun:
setTimeout(() => {}, 0);
 
// This will keep running:
setTimeout(() => {}, 1000);
// (Bun exits after the timeout fires)

3. TypeScript Configuration#

typescript
// Bun has its own tsconfig defaults
// If you're sharing a project between Bun and Node.js,
// be explicit in your tsconfig.json:
{
  "compilerOptions": {
    "target": "ESNext",
    "module": "ESNext",
    "moduleResolution": "bundler",
    "types": ["bun-types"]  // Add Bun type definitions
  }
}
bash
# Install Bun types
bun add -d @types/bun

4. Development में Hot Reload#

bash
# Bun has built-in watch mode
bun --watch run server.ts
 
# This restarts the process on file changes
# It's not HMR (Hot Module Replacement) — it's a full restart
# But because Bun starts so fast, it feels instant

5. bunfig.toml Configuration File#

toml
# bunfig.toml — Bun's config file (optional)
 
[install]
# Use a private registry
registry = "https://npm.mycompany.com"
 
# Scoped registries
[install.scopes]
"@mycompany" = "https://npm.mycompany.com"
 
[test]
# Test configuration
coverage = true
coverageReporter = ["text", "lcov"]
 
[run]
# Shell to use for bun run
shell = "bash"

मेरा Verdict#

एक साल production use के बाद, मैं यहां settle हुआ हूं:

आज मैं Bun कहां Use करता हूं#

सभी projects के लिए package manager — इस Next.js blog सहित। bun install faster है, और compatibility essentially perfect है। अब npm या yarn use करने का कोई reason नहीं दिखता। pnpm एकमात्र alternative है जिस पर consider करूंगा (monorepos में strict dependency resolution के लिए)।

Scripts और CLI tools के लिए runtime — कोई भी TypeScript file जो एक बार run करनी हो, bun से run करता हूं। कोई compilation step नहीं। Fast startup। Built-in .env loading। मेरे workflow में ts-node और tsx पूरी तरह replace हो चुके हैं।

छोटी APIs और internal tools के लिए runtime — Bun.serve() + bun:sqlite internal tools, webhook handlers, और छोटी services के लिए incredibly productive stack है। "One binary, no dependencies" deployment model compelling है।

Simple projects के लिए test runner — Straightforward test needs वाले projects के लिए, bun test fast है और zero configuration require करता है।

जहां मैं Node.js के साथ हूं#

Production Next.js — इसलिए नहीं कि Bun काम नहीं करता, बल्कि risk-reward अभी justify नहीं करता। Next.js complex framework है जिसमें बहुत सारे integration points हैं। इसके नीचे सबसे battle-tested runtime चाहता हूं।

Critical production services — मेरे main API servers PM2 के पीछे Node.js run करते हैं। Monitoring ecosystem, debugging tools, operational knowledge — सब Node.js है। Bun वहां पहुंचेगा, लेकिन अभी नहीं पहुंचा।

Native addons वाली कोई भी चीज़ — अगर dependency chain में C++ native addons हैं, Bun try भी नहीं करता। Compatibility issues debug करना worth नहीं।

Teams जो Bun से familiar नहीं — ऐसी team को Bun runtime introduce करना जिसने कभी use नहीं किया cognitive overhead add करता है। Package manager के रूप में, ठीक है। Runtime के रूप में, team ready होने तक wait करो।

क्या Watch कर रहा हूं#

Bun का compatibility tracker — जब Node.js APIs जो मुझे matter करती हैं उनके लिए 100% hit करेगा, तब reassess करूंगा।

Framework support — Next.js, Remix, और SvelteKit सबमें Bun support के varying levels हैं। जब इनमें से कोई officially Bun को production runtime support करेगा, वो signal है।

Enterprise adoption — जब real SLAs वाली companies production में Bun run करेंगी और इसके बारे में लिखेंगी, maturity question answer हो जाएगा।

1.2+ release line — Bun fast move कर रहा है। हर week features land होते हैं। आज मैं जो Bun use कर रहा हूं वो एक साल पहले try किए Bun से meaningfully better है।

Wrapping Up#

Bun silver bullet नहीं है। Slow app को fast नहीं बनाएगा और poorly designed API को well-designed नहीं बनाएगा। लेकिन JavaScript ecosystem के लिए developer experience में genuine improvement है।

Bun में जो मुझे सबसे ज़्यादा appreciate है वो कोई single feature नहीं। Toolchain complexity में reduction है। एक binary जो packages install करती है, TypeScript run करती है, code bundle करती है, और tests run करती है। Scripts के लिए tsconfig.json नहीं। Babel नहीं। Separate test runner config नहीं। बस bun run your-file.ts और काम करता है।

Practical advice: bun install से शुरू करो। Zero risk, immediate benefit। फिर scripts के लिए bun run try करो। फिर बाकी अपनी specific needs के basis पर evaluate करो। All-in जाने की ज़रूरत नहीं। Bun partial replacement के रूप में perfectly काम करता है, और शायद ज़्यादातर लोगों को आज ऐसे ही use करना चाहिए।

Bun के होने से JavaScript runtime landscape better है। Competition Node.js को भी better बना रही है — Node.js 22+ significantly faster हो गया है, partly Bun के pressure से। सब जीतते हैं।

संबंधित पोस्ट