Yarn工作区中peerDependencies的正确使用方式

理解peerDependencies的本质

在Yarn项目中，peerDependencies是一个特殊类型的依赖声明，它表示当前包需要宿主环境提供某些依赖项，而不是自己直接安装这些依赖。这种机制在开发可复用库时特别重要，因为它确保了库与宿主项目使用相同版本的依赖。

工作区中的peerDependencies问题

当在Yarn工作区中使用peerDependencies时，开发者可能会遇到一个常见误区：假设只要工作区中的某个包声明了peerDependency，其他工作区包就能自动满足这个依赖要求。实际上，Yarn要求每个工作区包都必须明确声明自己的依赖关系。

问题重现与分析

考虑一个典型场景：

• 工作区包含两个包：a和b
• 两个包都声明了对react^18的peerDependency
• 包a依赖包b

在这种情况下，Yarn会报告错误，指出包a没有提供react，而包b需要它。这是因为peerDependency只是声明了"需要什么"，而没有实际"提供什么"。

正确的解决方案

要解决这个问题，需要采取以下措施：

1. 保留peerDependencies声明：这表示你的包可以与这些依赖的指定版本范围兼容。

2. 添加devDependencies：为每个工作区包添加对应的devDependency，这样当包被独立使用时（没有上级项目提供依赖时），Yarn知道要安装什么。

3. 工作区根包的处理：虽然在工作区根package.json中声明依赖是常见做法，但这不足以保证所有工作区包的依赖需求。每个工作区包都需要自己的完整声明。

最佳实践建议

1. 双重声明策略：对于工作区中的每个包，同时使用peerDependencies和devDependencies声明关键依赖。

2. 版本一致性：确保工作区中各包对同一依赖的版本要求一致，避免潜在的冲突。

3. 明确依赖关系：不要依赖隐式的依赖共享，每个包都应该完整声明自己的需求。

4. 开发环境考量：devDependencies确保在独立开发和测试包时能获得必要的依赖。

与Yarn v1的区别

需要注意的是，这种行为与Yarn v1有所不同。在v1中，由于依赖提升(hoisting)机制，只要工作区中某个包声明了依赖，其他包可能就能访问到。但这种行为是不可靠的，因为：

• 无法控制实际获得的版本
• 不能保证依赖一定会被安装
• 导致隐式的依赖关系难以维护

Yarn的新版本要求更明确的依赖声明，这虽然增加了少量配置工作，但带来了更好的可预测性和可维护性。

总结

在Yarn工作区中正确使用peerDependencies需要理解其作为"需求声明"而非"提供声明"的本质。通过peerDependencies+devDependencies的双重声明策略，可以确保工作区包在各种使用场景下都能正确解析依赖关系。这种明确性虽然需要更多配置，但为项目带来了更好的长期可维护性。