如何使用replace屬性來避免Composer的依賴沖突

這篇文章將為大家詳細講解有關如何使用replace屬性來避免Composer的依賴沖突，小編覺得挺實用的，因此分享給大家做個參考，希望大家閱讀完這篇文章后可以有所收獲。

Composer 文檔提供了兩個基本的示例。 我將嘗試解釋一下：

列出被該軟件包替換的軟件包。 這樣，你就可以 fork 一個包，并使用自己的版本號以不同的名稱發布，而需要原始包的軟件包可以繼續使用你的 fork 包，因為它會替換原始包。

假設你的軟件使用 original/library 和 other/package，它們本身也需要 original/library。

現在你認為 original/library 需要集成新功能，但是維護人員不同意你的建議在他們的軟件包中實現。 所以你決定以  better/library 的名稱派生該庫，并標記一個新發行版。

回到軟件。當然，它應該開始使用 better/library 包，所以要用它來代替，但 other/package 仍然需要 original/library - 代碼重復！如何讓那個包使用你的 better/library 來代替 original/library？而不需要對它進行 fork ，只需要修改 composer.json（你仍然與 original/library 兼容，所以它應該可以工作了）？

你需要增加 replace 關鍵字在 composer.json ：

"replace": {
    "original/library":"1.0.2"
}

現在 Composer 知道，在解決 「other/package」的依賴關系時，任何來自 「better/library」的包都與「original/library」一樣好。

這對于包含子包的包也很有用，例如，主 symfony/symfony 包包含所有 Symfony 組件，這些組件也可以作為單獨的包使用。如果您需要主包，它將自動滿足單個組件之一的要求，因為它將替換它們。

相同的規則，只是角度略有不同：對于需要某些功能的任何其他組件，引入框架的組件是一種不錯的方法。但是，如果你在軟件中需要完整的框架，而另一個庫又需要該框架的組件，則該框架的 replace  聲明使 Composer 不必兩次安裝該單個組件，因為它已經包含在完整的框架中。

注意: 替換版本中的占位符通常是不好的

在我最初的回答中，我建議：

"replace": {
    "original/library":"1.*"
}

這帶來的后果是：Composer現在將把你的庫版本 1.0.0 和原來庫的任何版本 1.x 一樣好，即使他們在某一天修復了一些東西或添加了一些特性并發布了版本1.2.34。這也意味著，如果某一天你的「other/package」得到更新，并且需要「original/library:^1.1」，你庫中的替換仍處于活動狀態，并聲明它可以替換任何版本 1*，，即使你不更新內部的任何內容-這樣做也無法完成，但是如果你不做任何工作，你的舊代碼就永遠不會實現原始庫的新功能，但替換內容恰恰說明了這一點。

因此，從本質上講：在替換版本中避免使用通配符版本！ 如果使用它們，則會對你無法了解或預測的未來做出聲明（除非你可以控制 original/library ，但即使這樣也要非常小心）。 一定要使用你知道的并且可以完全重新實現的 original/library 。

關于“如何使用replace屬性來避免Composer的依賴沖突”這篇文章就分享到這里了，希望以上內容可以對大家有一定的幫助，使各位可以學到更多知識，如果覺得文章不錯，請把它分享出去讓更多的人看到。