
Bun Runtime
Choose Bun vs Node, migrate scripts and installs, and configure Bun on Vercel for a faster solo JS/TS toolchain.
Overview
bun-runtime is an agent skill most often used in Build (also Operate deploy config) that explains when to use Bun versus Node and how to migrate run, install, test, and Vercel settings.
Install
npx skills add https://github.com/affaan-m/everything-claude-code --skill bun-runtimeWhat is this skill?
- Single toolchain: runtime, bun install, bundler, and Jest-like bun test
- Clear Bun vs Node tradeoffs: speed and simplicity vs legacy ecosystem edge cases
- Node migration map: node → bun run, npm install → bun install, npx → bun x
- Lockfile note: bun.lock text default; older bun.lockb binary
- Vercel deployment guidance when Bun runtime is preferred
- Four Bun roles called out: runtime, package manager, bundler, and test runner
Adoption & trust: 4.3k installs on skills.sh; 210k GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
You want faster installs and one command for run/test/build but are unsure if Bun will break npm scripts, lockfiles, or your Vercel deployment.
Who is it for?
New JS/TS repos, speed-sensitive scripts, and Vercel projects where Bun runtime is an option and you want one agent-informed migration checklist.
Skip if: Stacks that depend on Node-only native addons or tooling with documented Bun incompatibilities where stability beats install speed.
When should I use this skill?
Adopting Bun, migrating from Node, writing or debugging Bun scripts/tests, or configuring Bun on Vercel or other platforms.
What do I get? / Deliverables
You pick Bun or Node with explicit criteria, update commands to bun install/run/x/test, and align deployment runtime settings before shipping.
- Updated run/install/test script conventions
- Bun-vs-Node decision notes and Vercel/runtime configuration guidance
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Runtime and package-manager decisions are made during Build when you wire how code runs, installs, tests, and bundles. Integrations captures toolchain and platform choices—Bun as drop-in runtime, lockfile, bundler, test runner, and Vercel runtime support.
Where it fits
Swap npm ci for bun install in a new API service and unify bun run dev with bun test in package scripts.
Set Vercel project runtime to Bun after validating dependencies locally.
Document bun x one-off CLIs for release automation instead of npx.
How it compares
Decision and migration skill for the JS runtime layer—not a framework-specific API reference or full test suite authoring guide.
Common Questions / FAQ
Who is bun-runtime for?
Solo and indie builders shipping JS/TS apps or CLIs who control package manager and runtime choice on laptop and host (including Vercel).
When should I use bun-runtime?
During Build when adopting Bun, replacing npm/yarn workflows, writing bun test suites, or configuring Vercel; during Operate when tuning deploy runtime after a Node-to-Bun switch.
Is bun-runtime safe to install?
It is documentation-style guidance; review the Security Audits panel on this page and pin Bun versions in CI after migration.
SKILL.md
READMESKILL.md - Bun Runtime
# Bun Runtime Bun is a fast all-in-one JavaScript runtime and toolkit: runtime, package manager, bundler, and test runner. ## When to Use - **Prefer Bun** for: new JS/TS projects, scripts where install/run speed matters, Vercel deployments with Bun runtime, and when you want a single toolchain (run + install + test + build). - **Prefer Node** for: maximum ecosystem compatibility, legacy tooling that assumes Node, or when a dependency has known Bun issues. Use when: adopting Bun, migrating from Node, writing or debugging Bun scripts/tests, or configuring Bun on Vercel or other platforms. ## How It Works - **Runtime**: Drop-in Node-compatible runtime (built on JavaScriptCore, implemented in Zig). - **Package manager**: `bun install` is significantly faster than npm/yarn. Lockfile is `bun.lock` (text) by default in current Bun; older versions used `bun.lockb` (binary). - **Bundler**: Built-in bundler and transpiler for apps and libraries. - **Test runner**: Built-in `bun test` with Jest-like API. **Migration from Node**: Replace `node script.js` with `bun run script.js` or `bun script.js`. Run `bun install` in place of `npm install`; most packages work. Use `bun run` for npm scripts; `bun x` for npx-style one-off runs. Node built-ins are supported; prefer Bun APIs where they exist for better performance. **Vercel**: Set runtime to Bun in project settings. Build: `bun run build` or `bun build ./src/index.ts --outdir=dist`. Install: `bun install --frozen-lockfile` for reproducible deploys. ## Examples ### Run and install ```bash # Install dependencies (creates/updates bun.lock or bun.lockb) bun install # Run a script or file bun run dev bun run src/index.ts bun src/index.ts ``` ### Scripts and env ```bash bun run --env-file=.env dev FOO=bar bun run script.ts ``` ### Testing ```bash bun test bun test --watch ``` ```typescript // test/example.test.ts import { expect, test } from "bun:test"; test("add", () => { expect(1 + 2).toBe(3); }); ``` ### Runtime API ```typescript const file = Bun.file("package.json"); const json = await file.json(); Bun.serve({ port: 3000, fetch(req) { return new Response("Hello"); }, }); ``` ## Best Practices - Commit the lockfile (`bun.lock` or `bun.lockb`) for reproducible installs. - Prefer `bun run` for scripts. For TypeScript, Bun runs `.ts` natively. - Keep dependencies up to date; Bun and the ecosystem evolve quickly.