作为 Javascript 开发者，我们都知道项目中存在两种不同的依赖项，dependency 和 devDependency，但是peerDependency 又如何呢？
在本系列中，我们将研究 Javascript 中这种不太常见的依赖关系。我们将研究它们是什么，作为图书馆用户我需要了解什么，以及图书馆作者的最佳实践是什么。
让我们回顾一下不同的常见类型：
依赖项：这些是您的应用程序中使用的工具；一个很好的例子是 React、Angular 和 Express。当您的应用程序投入生产时，依赖项上的库的代码将在后台运行并为您的应用程序提供动力。
devDependency：您将使用这些实用程序来构建您的应用程序。在这里，您将找到用于编译或解析代码的库以及用于运行测试的库。
当作者需要将特定库安装在工作区/项目中以使一切按预期工作时，他们将特定库指定为peerDependency。他们告诉 NPM（以及安装该库的开发人员）该包需要另一个包的特定版本（或版本范围）才能正常运行。尽管如此，用户仍负责安装和管理该依赖项。
让我们想象一个例子：您正在为您最喜欢的框架创建一个实用程序，该实用程序应该安装在您的库将运行的环境中。准确指定此场景的方法是使用 NPM peerDependency 功能。它为您的库的无缝集成提供了清晰的指南。
这种做法在充当“插件”的库中特别常见，因为它们需要指示正确功能的工作区要求。
我们来分析一个流行的React库，react-datepicker；如果我们看看它的 package.json 今天的样子，我们可以看出我们至少需要 React 版本 ^16.9.0 才能使 React-date 选择器正常工作。
"peerDependencies": {
"react": "^16.9.0 || ^17 || ^18",
"react-dom": "^16.9.0 || ^17 || ^18"
},
如果我们不遵守此要求，就会出现意外的行为。
当项目中的包依赖同一库的不同版本时，就会发生版本冲突。这可能会导致错误，特别是对于像 React 这样的库，共享同一实例对于状态管理和组件通信至关重要。如果没有peerDependency，可能会安装多个库版本，从而导致意外行为。
为了防止这些问题，peerDependency 允许包作者指定其包需要哪个版本的依赖项，而无需直接安装它。这将责任转移给使用该包的开发人员，确保他们安装单个兼容的依赖项版本。例如，像react-datepicker和react-router这样的库使用peerDependency来确保它们与项目中相同版本的React无缝工作。
想象一下这个场景：您正在创建一个库来共享 rxjs 的奇特运算符。如果您将 rxjs 设置为依赖项而不是peerDependency，您的库将安装它自己的 rxjs 版本。乍一看这似乎没什么大不了的，但实际上，它可能会导致版本冲突。
如果安装您的库的项目已经使用了不同版本的 rxjs，则可能会导致严重问题。应用程序最终可能会得到两个 rxjs 实例（一个来自您的库，一个来自项目本身）。由于 rxjs 严重依赖共享的可观察量和订阅，因此同时运行两个版本可能会导致不可预测的行为，例如流无法正确同步或丢失事件。
通过使用peerDependency来代替，你可以避免这个问题。你的包将向项目发出信号，表明它期望存在特定版本（或范围）的 rxjs，但它不会安装自己的版本。这样，该项目将使用您的库和代码库其他部分共享的单一版本的 rxjs，确保一切顺利和谐地运行。
peerDependency 可能不像依赖项或 devDependency 那样被广泛讨论，但它们在确保复杂项目中的兼容性和避免版本冲突方面发挥着关键作用。通过明确定义库需要哪个版本的共享依赖项而不直接安装它，peerDependency 允许开发人员保持对其项目环境的控制。
第一篇文章的目标是为peerDependency 创建一个良好的理解基础。在本系列的下一章中，我们将以更实用的方式探索作为具有peerDependency的库的用户的peerDependency的不同方面，如何克服常见问题，以及它们在不同的javascript包管理器中的行为方式。
以上是NPM 对等依赖关系深入：全面介绍的详细内容。更多信息请关注PHP中文网其他相关文章！
