Bun 包管理器：锁文件、CI 与依赖安全

高频命令

bun install              # 安装 package.json 中的依赖
bun add zod              # 添加生产依赖
bun add -d typescript    # 添加开发依赖
bun remove zod           # 删除依赖
bun update               # 按版本范围更新
bun outdated             # 查看可更新包
bun audit                # 审计已知漏洞
bunx <package>           # 执行包提供的 CLI
bun pm untrusted         # 列出被阻止的依赖安装脚本

锁文件

bun install 默认生成文本格式 bun.lock。应将它提交到版本控制；CI 优先使用语义更明确的命令：

bun ci

bun ci 等价于 bun install --frozen-lockfile：manifest 与锁文件不一致时直接失败。

在没有 bun.lock 时，Bun 能迁移 package-lock.json、yarn.lock 或 pnpm-lock.yaml，并保留原文件。正确流程是：

在独立分支运行一次 bun install。
审查 bun.lock 和 package.json 变化。
跑完整测试与构建。
确认团队切换后再移除旧锁文件，避免长期维护两个真相源。

工作区

package.json

{
  "name": "acme-workspace",
  "private": true,
  "workspaces": ["apps/*", "packages/*"]
}

内部依赖使用工作区协议：

{
  "dependencies": {
    "@acme/shared": "workspace:*"
  }
}

bun install --filter './apps/web'
bun run --filter '*' test

需要 Catalog、依赖隔离和任务编排时，继续阅读 Monorepo 与 Workspaces。

`bunfig.toml`

只在需要 Bun 特有行为时创建：

[install]
exact = true

[install.lockfile]
save = true

优先复用 package.json、tsconfig.json 等生态标准配置，不要把所有设置搬进 bunfig.toml。

CI 基线

- uses: oven-sh/setup-bun@v2
- run: bun ci
- run: bun run typecheck
- run: bun test
- run: bun run build

生命周期脚本与供应链

Bun 默认不会运行任意依赖的 lifecycle scripts，但会信任一份内置默认列表，并允许项目通过 trustedDependencies 放行依赖。不要因此把安装过程视为无代码执行：

bun pm untrusted               # 查看哪些脚本被阻止
bun pm trust <package>         # 审查后再放行指定包
bun install --ignore-scripts   # 高风险 CI 的更严格模式；先验证依赖是否仍可用
bun audit --prod               # 仅审计生产依赖；Workspace 根目录有过滤缺陷，需实测

对新依赖还可设置最短发布时间，降低刚发布恶意版本立即进入构建的风险：

bunfig.toml

[install]
minimumReleaseAge = 259200 # 3 days, seconds

最低发布时间只影响新解析的版本，已经存在于 bun.lock 的版本保持不变。bun add -E <package> 可以固定直接依赖版本，但完整依赖图仍由锁文件负责。

信任是代码执行授权

提交 trustedDependencies 前，检查包来源、版本、脚本内容和锁文件差异。不要为了让 CI 变绿而批量信任所有包。

官方参考：Package manager、Lockfile、Lifecycle scripts、Audit。