bun-development

Bun Development

Navigation hub for Bun guidance focused on production-safe implementation.

Philosophy

• Prefer Bun-native APIs over Node.js shims: one runtime, one set of semantics.
• Treat every string that crosses a shell or SQL boundary as hostile until it is bound or passed as an argument.
• Keep installs deterministic: one package manager, one lockfile, no drift.
• Validate every change by running it, not by reading it.

When to Use

• You need Bun-native runtime APIs (Bun.file, Bun.write, Bun.serve)
• You are writing or debugging tests with bun test
• You are adding bun:sqlite usage with transactions or prepared statements
• You are setting dependency/workspace policy in a Bun project
• You need deterministic security guardrails for shell/SQL inputs

When Not to Use

• The project standard runtime is strictly Node.js with no Bun support
• You need framework-specific guidance not covered by Bun APIs
• The task is only package-agnostic JavaScript refactoring

Workflow

1. Confirm Bun is available and lock dependency strategy.
2. Choose the category (runtime, file I/O, testing, sqlite, package, security).
3. Implement with copy/paste commands from Quick Commands.
4. Apply anti-pattern checks before finalizing.
   • If bun install fails: check bun.lock/bun.lockb for merge conflicts, resolve them, and re-run bun install.
   • If tests fail after dependency changes: run bun test to isolate regressions before proceeding.
5. Validate behavior with tests or execution checks.
   • If validation fails: revert the last change, confirm the error, and address the specific failure before re-validating.
6. For SQL validation (rg finds non-prepared statements in existing code): refactor each flagged call to use db.prepare(...) with bound parameters before merging; do not leave raw interpolations in place.
7. Document decisions with links to exact references used.

Quick Commands

Verify Runtime

bun --version

Expected: a Bun version is printed.