Yarn Workspaces中如何为不同子项目配置差异化resolutions规则

Yarn 1（Classic）原生的全局resolutions规则不支持按工作区维度为同一个依赖指定不同版本，你之前尝试的"A/foo": "1.0.0"写法不符合resolutions的路径匹配逻辑，因此不会生效。

Yarn 1的resolutions路径匹配是沿依赖树的父子层级做匹配，A/foo的语义是「父级依赖为A包的foo实例」，既无法覆盖A包下所有传递依赖引入的foo，也无法阻止Yarn的依赖提升机制把符合版本要求的foo安装到根目录node_modules，最终两个工作区还是会加载到同一个提升后的foo版本。

方案1：Yarn 1 环境下用 nohoist + 子包resolutions实现 #

子包内单独写resolutions不生效的核心原因，是依赖被提升到根目录后，子包的resolutions规则不会作用于被提升的依赖，搭配nohoist把对应工作区的foo相关依赖留在子包本地即可解决：

1. 在根目录package.json中修改workspaces配置，添加nohoist规则，阻止foo及其子依赖被提升：

{
  "workspaces": {
    "packages": ["packages/*"],
    "nohoist": [
      "A/foo",
      "A/foo/**",
      "B/foo",
      "B/foo/**"
    ]
  }
}

2. 分别在A、B两个子包的package.json中配置各自的resolutions规则：
   A包配置：

{
  "resolutions": {
    "foo": "1.0.0"
  }
}

B包配置：

{
  "resolutions": {
    "foo": "2.0.0"
  }
}

3. 清除现有依赖缓存：删除根目录及所有子包的node_modules文件夹、根目录的yarn.lock文件，重新执行yarn install即可生效。

注意：nohoist规则必须同时覆盖foo本身和foo的所有传递依赖（即带/**的匹配项），否则foo的内部依赖仍会被提升到根目录，可能出现版本冲突或实例不唯一的问题。

方案2：升级到Yarn 2+（Berry）使用原生工作区resolutions能力 #

如果项目允许升级Yarn版本，Yarn 2及以上版本原生支持按工作区维度锁定依赖版本，不需要额外配置nohoist，直接在根目录package.json中写resolutions即可：

{
  "resolutions": {
    "foo@workspace:A": "1.0.0",
    "foo@workspace:B": "2.0.0"
  }
}

该配置会精准将A工作区下所有引入的foo（包括深层传递依赖）锁定为1.0.0版本，B工作区下的foo锁定为2.0.0版本，不会受依赖提升影响，是长期维护成本最低的方案。

方案3：极端场景下用依赖别名兜底 #

如果既无法升级Yarn版本，nohoist配置后仍存在传递依赖漏匹配的情况，可以通过依赖别名绕开：在两个子包中分别为不同版本的foo设置独立别名，再配合构建工具（Webpack、Rollup等）的模块别名规则，将所有代码和依赖中对foo的引用映射到对应别名的版本上，该方案配置成本较高，仅建议在复杂传递依赖场景下使用。

内容的提问来源于stack exchange，提问作者Ruben Aguilar