作為 Javascript 開發者，我們都知道專案中存在兩種不同的依賴關係，dependency 和 devDependency，但是peerDependency 又如何呢？

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

NPM 中的依賴關係是什麼

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

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

• devDependency：您將使用這些實用程式來建立您的應用程式。在這裡，您將找到用於編譯或解析程式碼的程式庫以及用於執行測試的程式庫。

什麼是peerDependency

當作者要求將特定庫安裝在工作區/專案中以使一切按預期工作時，他們將特定庫指定為peerDependency。他們告訴 NPM（以及安裝該程式庫的開發人員）該套件需要另一個套件的特定版本（或版本範圍）才能正常運作。儘管如此，用戶仍負責安裝和管理該依賴項。

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

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

peerDependency 的真實例子

我們來分析一個流行的React庫，react-datepicker；如果我們看看它的package.json 今天的樣子，我們可以看出我們至少需要React 版本^16.9.0 才能使反應日期選擇器正常工作。

"peerDependencies": {
  "react": "^16.9.0 || ^17 || ^18",
  "react-dom": "^16.9.0 || ^17 || ^18"
},

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

peerDependency 解決的挑戰

當專案中的套件依賴同一庫的不同版本時，就會發生版本衝突。這可能會導致錯誤，特別是對於像 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包管理器中的行為方式。