跳到主要内容

包管理、bunx 与脚本执行

对很多前端项目来说，Bun 最容易先落地的一层不是 runtime，而是包管理和脚本执行。

因为这条线切进去之后，最先会碰到的是这些动作：

  • 安装依赖
  • 增删依赖
  • 跑 package.json 脚本
  • 运行一次性 CLI
  • 管 lockfile

这一层和现有项目的摩擦通常最小。

最常见的命令​

bun install
bun add axios
bun add -d typescript
bun remove lodash
bun update
bun run dev
bun run build
bunx create-vite

如果平时已经习惯 npm、pnpm 或 yarn，上手成本不高。

bun install 更该看哪些层​

官方安装文档和 CLI 文档里，别只盯着 benchmark，更值得看的是这几层：

  • lockfile
  • lifecycle scripts
  • node_modules 组织
  • workspaces
  • frozen lockfile

lockfile​

Bun 当前主线 lockfile 是：

  • bun.lock

团队项目里更稳的做法通常是：

  • 提交 bun.lock
  • 团队统一使用 Bun 安装
  • 不混用多个包管理器来回改 lockfile

frozen lockfile​

CI 里常见会直接写：

bun install --frozen-lockfile

这层的价值很直接：

  • 保证 CI 不偷偷改依赖树
  • 保证 lockfile 和安装结果一致
  • 让本地与 CI 的差异尽量变少

bunx 怎么看​

bunx 和 npx 的角色很接近，但放在 Bun 这套工具里，路径会更统一。

例如：

bunx create-vite
bunx eslint .
bunx prettier . --check

比较常见的好处：

  • 一次性 CLI 不用再切 npx
  • 工程工具命令入口更统一
  • 和 bun run 配合时心智更简单

bun run 在团队项目里为什么很关键​

Bun 对很多团队最大的日常影响，不一定是安装速度，而是 bun run。

{
  "scripts": {
    "dev": "vite",
    "build": "tsc && vite build",
    "lint": "eslint .",
    "test": "vitest"
  }
}

这类项目里直接：

bun run dev
bun run lint
bun run test

就已经能覆盖很大一部分日常动作。

生命周期脚本要单独看​

Bun 官方文档专门提到 lifecycle script 管理。这一层非常关键，因为很多真实项目并不是“依赖装不上”，而是：

  • postinstall 没按预期执行
  • 原生模块初始化出问题
  • 代码生成流程没跑完

所以遇到这些依赖时，迁前最好拿真实仓库跑：

  • install
  • lint
  • test
  • build

而不是只看 bun install 是否成功。

什么时候适合先只切这一层​

  • 现有项目主要还是前端应用
  • runtime 还不想动
  • 先想试安装和脚本体验
  • monorepo 想先做小范围试点

这通常是最稳的第一步。

参考来源​