bun-package-managerlisted

# Bun Package Manager ## Overview Bun best practices for frontend projects: - Bun commands (add, remove, update, run, x) - Lockfile management (`bun.lock` text vs `bun.lockb` binary) - `bunfig.toml` configuration - Workspace support (monorepos) - CI/CD integration - Troubleshooting common issues - Bun-native tooling primer (`bun test`, `bun build`, Bun runtime) --- ## Hard Rules <HARD-RULES> These rules are NON-NEGOTIABLE. Violating any of them is a bug. - ALWAYS use `bun` for all package operations — NEVER `npm`, `yarn`, or `pnpm` in Bun projects - ALWAYS use `bun run <script>` (or implicit `bun <script>`) — NEVER `npm run`/`yarn`/`pnpm run` - ALWAYS commit exactly one Bun lockfile (`bun.lock` preferred, `bun.lockb` for legacy projects) — the lockfile MUST be in version control and the two formats MUST NOT coexist - PREFER `bun.lock` (text) over `bun.lockb` (binary) — Bun 1.2+ default, diff-friendly in PRs; migrate via `bun install --save-text-lockfile` when feasible - ALWAYS use `bunx` instead of `npx` for one-off package execution - ALWAYS use `--frozen-lockfile` in CI — NEVER allow lockfile modifications in CI - NEVER delete the lockfile to "fix" issues — resolve the underlying problem - NEVER mix package managers — if `pnpm-lock.yaml` or `package-lock.json` exists, use that manager - ALWAYS check for existing lockfile before running `bun install` in a new project </HARD-RULES> --- ## Detecting Bun Projects Before using Bun commands, verify the project uses Bun: