13518219792
这篇文章将为大家详细讲解有关如何使用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的依赖冲突”这篇文章就分享到这里了，希望以上内容可以对大家有一定的帮助，使各位可以学到更多知识，如果觉得文章不错，请把它分享出去让更多的人看到。
