Yarn

Yarn 以只读方式支持。安装和运行工作；任何会重写 yarn.lock 的命令在引擎触碰任何东西之前拒绝：

$ nub add lodash
Error: nub add: refusing to modify yarn.lock —
       adding a dependency re-resolves and rewrites yarn.lock
  Run it with yarn directly:
    yarn add lodash

Nub 读取 yarn.lock 来安装和运行项目但从写入它。继续使用 yarn 处理任何更改依赖图的操作。

两种格式都被读取：

• Classic — 没有 __metadata 块的 yarn.lock（Yarn 1.x）。
• Berry — __metadata / version 格式（Yarn 2+）。

配置

运行 Yarn 项目

nub install        # 读取 yarn.lock，链接 node_modules，运行生命周期脚本
nub ci             # 冻结安装：yarn.lock 是法律；漂移是硬错误
nub run <script>   # 运行 package.json 脚本
nubx <bin>         # 一次性二进制执行

package.json 中的顶层 resolutions 被遵守——Nub 按 Yarn 的方式应用它。顶层 overrides 是 npm 和 Bun 的固定字段；Yarn 忽略它，Nub 在 Yarn 现任者下也是如此——将固定放在 resolutions 中。packageManager 字段是告诉 Nub 项目是 Yarn 项目的标志。

被拒绝的命令

用 yarn 运行这些：

nub add <pkg>       # → yarn add
nub remove <pkg>    # → yarn remove
nub update          # → yarn upgrade
nub dedupe          # → yarn dedupe

同样的门在会重写而非只读取锁文件的 install / ci 上触发：声明 Yarn 但尚无 yarn.lock 的项目、nub install --force / --no-frozen-lockfile / --lockfile-only，或不再满足 package.json 的 yarn.lock。用 yarn install 处理这些。

没有转换到 yarn.lock 的路径。nub import 命令产生 pnpm-lock.yaml：

$ nub import        # 在 yarn 项目中
Imported 2 packages from yarn.lock to pnpm-lock.yaml

配置文件

Nub 读取 .npmrc 获取注册表、认证、scope、CA 和代理设置。在 Yarn 现任者项目中，Nub 还读取一小部分能干净映射到其现有注册表和 linker 模型的 .yarnrc.yml 子集：

• npmRegistryServer 成为默认注册表。
• npmScopes.<scope>.npmRegistryServer 成为 scope 注册表。
• npmAuthToken 和 npmAuthIdent 在可附加到已知注册表时应用，包括 npmRegistries 条目。
• Scope 级别认证（npmScopes.<scope>.npmAuthToken / npmAuthIdent）仅在该 scope 有自己唯一的自定义 npmRegistryServer 时应用。无自定义注册表的 scope 认证、共享注册表的 scope 认证，或也有 npmRegistries 条目的注册表的 scope 认证被跳过而非扩展为注册表范围的凭据。
• nodeLinker: node-modules 映射到 Nub 的提升 linker。
• nodeLinker: pnpm 映射到 Nub 的隔离 linker。
• httpsCaFilePath 成为 CA 文件，networkSettings.<host>.httpsCaFilePath 成为每主机 CA。
• httpProxy / httpsProxy 设置代理，enableStrictSsl 映射到 strict-SSL。
• packageExtensions 以与 pnpm 的相同方式合并，dependenciesMeta.*.built 控制哪些包运行构建脚本。
• YARN_NPM_REGISTRY_SERVER、YARN_NPM_AUTH_TOKEN、YARN_NPM_AUTH_IDENT、YARN_NODE_LINKER，以及顶层 CA、代理和 strict-SSL 环境值在 .yarnrc.yml 之上为相同子集被识别。当环境接口也提供其所属注册表时，顶层认证环境值附加；scope 和 map 形态的 Yarn 环境配置不被翻译。

与其他地方相同的品牌边界适用：.yarnrc.yml 仅在项目实际是 Yarn 拥有时被读取，通过 packageManager: "yarn@..." 或 Yarn 锁文件。Nub 身份项目不消费 Yarn 配置。

# .yarnrc.yml — Yarn 现任者项目中支持的子集
npmRegistryServer: https://registry.internal/
npmScopes:
  myorg:
    npmRegistryServer: https://npm.myorg.dev/
    npmAuthToken: "<token>"
npmRegistries:
  "https://npm.myorg.dev":
    npmAuthIdent: "user:pass"
nodeLinker: node-modules

Nub 读取全局 ~/.yarnrc.yml 加上从工作区根目录到当前项目目录的任何项目 .yarnrc.yml 文件；更近的项目文件优先。支持是故意窄的。仍忽略：每主机 networkSettings 代理（Nub 应用的代理是进程范围的）、约束、插件、补丁文件夹配置和 Yarn 缓存布局。

经典 .yarnrc（Yarn 1）对其核心注册表和认证字段得到相同的基本处理。其键已是 npmrc 形态，所以 Nub 直接读取它们：

# .yarnrc — Yarn 现任者项目中支持的核心字段
registry "https://registry.internal/"
"@myorg:registry" "https://npm.myorg.dev/"
"//npm.myorg.dev/:_authToken" "<token>"

发现镜像经典 Yarn：全局 ~/.yarnrc 加上从文件系统根到当前目录的任何项目 .yarnrc 文件，更近的文件优先。只读取默认注册表、scope 注册表和注册表键或顶层认证（_authToken / _auth）；其他所有经典键——network-timeout、save-prefix、yarn-offline-mirror、--flag 参数行等——被忽略。

Node linker

Nub 映射它能表示的 Yarn linker 设置：

# .yarnrc.yml
nodeLinker: node-modules  # 提升的 node_modules
nodeLinker: pnpm          # 隔离符号链接布局
nodeLinker: pnp           # ❌ 警告；改为安装 node_modules

Yarn Berry 在 nodeLinker 缺失时默认为 PnP。安装时，Nub 打印一个警告并链接 node_modules 树：

# 捕获：nub 0.1.1，无 nodeLinker 的 Yarn Berry 锁文件
$ nub install
nub: this Yarn project uses Plug'n'Play (nodeLinker: pnp or Yarn
     Berry's default), which nub does not implement — installing a
     node_modules tree instead. [WARN_NUB_PNP_LINKER_DOWNGRADE]
nub 0.1.1 · ✓ Already up to date

Nub 运行时完全支持 Plug'n'Play。 如果项目已被 Yarn 以 PnP 模式安装，Nub 可以运行它——nub <file>、nub run 和 nubx 在所有支持的 Node 版本上遵守 .pnp.cjs。Nub 不能做的是产生 PnP 安装。所以 PnP 项目的支持工作流是：用 yarn 安装，用 nub 运行。参见 Plug'n'Play 解析了解 Nub 如何在运行时解析 PnP 项目。

差距

几个 Yarn package.json 和 .yarnrc.yml 字段在 Nub 下仍无效：

• 每主机 networkSettings 代理——Nub 应用的代理是进程范围的，不是每注册表主机。
• nodeLinker: pnp——PnP 安装生成不在范围内；Nub 警告并改为链接 node_modules。用 Yarn 安装，用 Nub 运行。