作為 Javascript 開發(fā)者，我們都知道項目中存在兩種不同的依賴項，dependency 和 devDependency，但是peerDependency 又如何呢？

在本系列中，我們將研究 Javascript 中這種不太常見的依賴關系。我們將研究它們是什么，作為圖書館用戶我需要了解什么，以及圖書館作者的最佳實踐是什么。

NPM 中的依賴是什么

讓我們回顧一下不同的常見類型：

• 依賴項：這些是您的應用程序中使用的工具；一個很好的例子是 React、Angular 和 Express。當您的應用程序投入生產時，依賴項上的庫的代碼將在后臺運行并為您的應用程序提供動力。

• devDependency：您將使用這些實用程序來構建您的應用程序。在這里，您將找到用于編譯或解析代碼的庫以及用于運行測試的庫。

什么是peerDependency

當作者需要將特定庫安裝在工作區(qū)/項目中以使一切按預期工作時，他們將特定庫指定為peerDependency。他們告訴 NPM（以及安裝該庫的開發(fā)人員）該包需要另一個包的特定版本（或版本范圍）才能正常運行。盡管如此，用戶仍負責安裝和管理該依賴項。

讓我們想象一個例子：您正在為您最喜歡的框架創(chuàng)建一個實用程序，該實用程序應該安裝在您的庫將運行的環(huán)境中。準確指定此場景的方法是使用 NPM peerDependency 功能。它為您的庫的無縫集成提供了清晰的指南。

這種做法在充當“插件”的庫中特別常見，因為它們需要指示正確功能的工作區(qū)要求。

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"
},

如果我們不遵守此要求，就會出現意外的行為。

peerDependency 解決的挑戰(zhàn)

當項目中的包依賴同一庫的不同版本時，就會發(fā)生版本沖突。這可能會導致錯誤，特別是對于像 React 這樣的庫，共享同一實例對于狀態(tài)管理和組件通信至關重要。如果沒有peerDependency，可能會安裝多個庫版本，從而導致意外行為。

為了防止這些問題，peerDependency 允許包作者指定其包需要哪個版本的依賴項，而無需直接安裝它。這將責任轉移給使用該包的開發(fā)人員，確保他們安裝單個兼容的依賴項版本。例如，像react-datepicker和react-router這樣的庫使用peerDependency來確保它們與項目中相同版本的React無縫工作。

另一個例子

想象一下這個場景：您正在創(chuàng)建一個庫來共享 rxjs 的奇特運算符。如果您將 rxjs 設置為依賴項而不是peerDependency，您的庫將安裝它自己的 rxjs 版本。乍一看這似乎沒什么大不了的，但實際上，它可能會導致版本沖突。

如果安裝您的庫的項目已經使用了不同版本的 rxjs，則可能會導致嚴重問題。應用程序最終可能會得到兩個 rxjs 實例（一個來自您的庫，一個來自項目本身）。由于 rxjs 嚴重依賴共享的可觀察量和訂閱，因此同時運行兩個版本可能會導致不可預測的行為，例如流無法正確同步或丟失事件。

通過使用peerDependency來代替，你可以避免這個問題。你的包將向項目發(fā)出信號，表明它期望存在特定版本（或范圍）的 rxjs，但它不會安裝自己的版本。這樣，該項目將使用您的庫和代碼庫其他部分共享的單一版本的 rxjs，確保一切順利和諧地運行。

結論

peerDependency 可能不像依賴項或 devDependency 那樣被廣泛討論，但它們在確保復雜項目中的兼容性和避免版本沖突方面發(fā)揮著關鍵作用。通過明確定義庫需要哪個版本的共享依賴項而不直接安裝它，peerDependency 允許開發(fā)人員保持對其項目環(huán)境的控制。

第一篇文章的目標是為peerDependency 創(chuàng)建一個良好的理解基礎。在本系列的下一章中，我們將以更實用的方式探索作為具有peerDependency的庫的用戶的peerDependency的不同方面，如何克服常見問題，以及它們在不同的javascript包管理器中的行為方式。

以上是NPM 對等依賴關系深入：全面介紹的詳細內容。更多信息請關注PHP中文網其他相關文章！