使用replace屬性來避免Composer的依賴衝突

# 。

Composer 文件提供了兩個基本的範例。我將嘗試解釋：列出被該軟體包替換的軟體包。這樣，你就可以 fork 一個包，並使用自己的版本號以不同的名稱發布，而需要原始包的軟體包可以繼續使用你的 fork 包，因為它會替換原始包。

假設你的軟體使用

和

other/package

，它們本身也需要

。現在你認為original/library需要整合新功能，但是維護人員不同意你的建議在他們的軟體包中實現。所以你決定以better/library的名稱衍生出該函式庫，並標記一個新發行版。

回到軟體。當然，它應該開始使用better/library套件，所以要用它來代替，但other/package仍然需要

- 程式碼重複！如何讓那個套件使用你的better/library來取代original/library？而不需要對它進行 fork ，只需要修改 composer.json（你仍然與original/library相容，所以它應該可以工作了）？你需要增加replace 關鍵字在composer.json：

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

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

相同的規則，只是角度略有不同：對於需要某些功能的任何其他元件，引入框架的元件是一種不錯的方法。但是，如果你在軟體中需要完整的框架，而另一個庫又需要該框架的元件，則該框架的

聲明使Composer 不必兩次安裝該單一元件，因為它已經包含在完整的框架中。

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

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

這帶來的後果是：Composer現在將把你的庫版本1.0.0 和原來庫的任何版本1.x 一樣好，即使他們在某一天修復了一些東西或添加了一些特性並發布了版本1.2.34 。這也意味著，如果某一天你的「other/package」得到更新，並且需要「original/library:^1.1」，你庫中的替換仍處於活動狀態，並聲明它可以替換任何版本

，，即使你不更新內部的任何內容-這樣做也無法完成，但是如果你不做任何工作，你的舊代碼就永遠不會實現原始庫的新功能，但替換內容恰恰說明了這一點。

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

原文網址：https://stackoverflow.com/questions/18882201/how-does-the-replace-property-work-with-composer#翻譯網址：https: //learnku.com/laravel/t/55200

以上是使用replace屬性來避免Composer的依賴衝突的詳細內容。更多資訊請關注PHP中文網其他相關文章！