Yarn 4工作区中peerDependencies的注意事项与解决方案

在Yarn 4工作区环境中，开发者可能会遇到一个典型问题：当某个工作区包声明了peerDependencies时，Yarn会提示"doesn't provide"警告。这种情况通常发生在升级到Yarn 4.3.1及更高版本后，特别是在使用像expo-secure-store这类具有严格peer依赖要求的包时。

问题本质

Yarn工作区包具有双重身份特性：

1. 作为其他工作区的依赖项时，其peerDependencies会被正常解析
2. 作为独立根包运行时（如直接在该包目录执行yarn run），由于没有父级包，peerDependencies将无法被自动提供

这种设计源于Yarn对工作区包的特殊处理机制。当工作区包作为依赖被其他包引用时，它能正常继承父级包的依赖；但当它作为独立入口点时，就失去了这种继承关系。

解决方案

对于需要同时支持两种使用场景的工作区包，推荐采用组合声明方式：

{
  "peerDependencies": {
    "expo": "*",
    "react-native": ">=0.60"
  },
  "devDependencies": {
    "expo": "^50.0.0",
    "react-native": "0.73.0"
  }
}

这种配置确保了：

• 作为依赖时，peerDependencies会被正确继承
• 独立运行时，devDependencies会提供必要的环境支持

最佳实践建议

1. 版本一致性：保持peerDependencies和devDependencies中相同包的大版本一致
2. 最小化声明：peerDependencies范围应尽可能宽松，devDependencies则可具体化
3. 文档说明：在项目文档中明确说明这种双重声明的必要性
4. 依赖隔离：对于工具类工作区包，考虑将其devDependencies提升到根workspace

理解Yarn工作区的这种双重特性，能帮助开发者更好地组织复杂项目中的依赖关系，避免因peerDependencies导致的构建问题。这种模式也体现了现代JavaScript生态中依赖管理的灵活性要求。

对于大型monorepo项目，建议建立统一的依赖管理规范，确保所有工作区包都遵循相同的peerDependencies处理原则，这样可以显著降低维护成本。