Bun

当 Bun 是现任包管理器时，Nub 针对它安装且不写入自己的锁文件。bun.lock 文本锁文件逐字节往返；trustedDependencies、overrides / resolutions、patchedDependencies，以及工作区和目录都按 Bun 解析的方式解析。以下所有内容都以 Bun 是现任者为前提——packageManager: "bun@…" 字段或现有的 bun.lock。

配置

bun.lock

文本锁文件（Bun 1.2+ 默认）被读取、写入并原样保留。

# 捕获：nub 0.0.44 — 在 bun.lock 项目中安装，然后 diff 锁文件
$ nub install
dependencies:
+ is-odd@3.0.1

nub 0.0.44 · ✓ installed 2 packages in 38ms

$ diff bun.lock bun.lock.orig    # ✓ 逐字节相同（无输出）
$ ls pnpm-lock.yaml              # ✓ 未写入外部锁文件
ls: pnpm-lock.yaml: No such file or directory

bun.lockb

旧版二进制锁文件（1.2 之前）不被读取。只有 bun.lockb 而无文本 bun.lock 时，Nub 预先拒绝而非猜测或回退到其他格式：

# 捕获：nub 0.0.44 — 只有 bun.lockb 的项目
$ nub install
ERR_NUB_LOCKFILE_PARSE          # ❌ 二进制格式被拒绝

  × failed to parse lockfile
  ╰─▶ failed to parse lockfile /path/to/bun.lockb: bun.lockb
      (binary format) is not supported — run `bun install --save-text-
      lockfile` to generate a bun.lock text file first, or upgrade to bun 1.2+
      where text is the default

运行一次 bun install --save-text-lockfile 来迁移，然后 Nub 往返生成的 bun.lock。

trustedDependencies

Bun 通过 package.json 中的 trustedDependencies 白名单控制依赖构建脚本。当 Bun 是现任者时 Nub 完全镜像它：列出的包运行其 install/postinstall 脚本，其他一切安装但不构建。

// package.json
{
  "dependencies": { "esbuild": "0.21.5" },
  "trustedDependencies": ["esbuild"]
}

# 捕获：nub 0.0.44 — esbuild 不在 trustedDependencies 中 — 构建跳过
$ nub install
dependencies:
+ esbuild@0.21.5

nub 0.0.44 · ✓ installed 2 packages in 33ms
WARN ignored build scripts for 1 package(s): esbuild@0.21.5.
     Run `nub approve-builds` to review and enable them, or set
     `strictDepBuilds=true` to fail installs that have unreviewed builds.
     code=WARN_NUB_IGNORED_BUILD_SCRIPTS count=1 packages=["esbuild@0.21.5"]

# 捕获：nub 0.0.44 — esbuild 在 trustedDependencies 中 — 构建运行
$ nub install
dependencies:
+ esbuild@0.21.5

nub 0.0.44 · ✓ installed 2 packages in 35ms

Nub 的精选默认信任下限开启，但在 bun.lock 上无效：其冷却窗口门需要每包发布时间数据，而 bun.lock 不携带，所以失败关闭。只有 trustedDependencies 构建任何东西——完全是 Bun 的模型。

bunfig.toml

当 Bun 是现任包管理器时，Nub 读取 Bun 配置的一小部分安装专用子集：项目 bunfig.toml，以及来自 XDG_CONFIG_HOME（或未设置时 HOME）的全局 .bunfig.toml。项目配置优先于全局配置。

今日支持的：

• [install].registry 作为字符串 URL 或 { url, token, username, password } 对象。没有 url 的仅认证对象应用于默认 npm 注册表。
• [install.scopes] 条目作为字符串 URL 或注册表对象。仅认证的 scope 对象继承 [install].registry，或未配置默认时的默认 npm 注册表，用于注册表路由。
• [install].linker = "hoisted" | "isolated"，映射到 Nub 现有的 nodeLinker。
• [install].cafile（PEM 文件路径）和 [install].ca（内联 PEM，单字符串或数组），映射到与 .npmrc cafile / ca 键相同的 TLS 信任。

加上环境中的 BUN_CONFIG_REGISTRY 和 BUN_CONFIG_TOKEN，它们设置默认注册表及其认证令牌并优先于文件配置。

Nub 身份、npm、pnpm、yarn 和新项目不读取 bunfig.toml；该文件是 Bun 拥有的配置，在 Bun 不是现任者时保持无效。此启动子集是尽力而为：不可读或无效的 TOML 被忽略而非导致安装失败。

差距

• 仅安装的 bunfig.toml。 [install] 键（注册表、scope、linker、TLS）被读取；运行时/测试/服务字段、安全扫描器、缓存和全局目录行为，以及更广泛的 BUN_CONFIG_* 安装行为族（重试、锁文件和跳过开关）无效。自定义 CA 通过 bunfig 自身的 [install] cafile 和 ca 键以及 .npmrc 工作——.npmrc cafile / ca 键（顶层和每注册表）在每个现任者下工作，参见自定义 CA。对于必须跨工具共享的注册表、认证或 TLS，.npmrc 是最通用的归宿：

  # .npmrc — nub 和 bun 都遵守
  //registry.example.com/:_authToken=${NPM_TOKEN}
  @myscope:registry=https://registry.example.com/
  cafile=./corp-ca.pem

  使用与默认注册表相同注册表 URL 的 scope 本地凭据在 Nub 当前的注册表模型中也无法忠实表示。Nub 保持 scope 注册表路由，但不将这些凭据扩展为注册表范围的认证。

• 无 bun.lockb。 二进制锁文件被拒绝而非迁移——先运行 bun install --save-text-lockfile 生成 bun.lock。

• 默认信任下限在 bun.lock 上无效。 无发布时间数据意味着精选包不被自动信任；只有 trustedDependencies 构建。