如何使用 replace 属性来避免 Composer 的依赖冲突?

Laravel

Composer 文档提供了两个基本的示例。 我将尝试解释一下:

列出被该软件包替换的软件包。 这样,你就可以 fork 一个包,并使用自己的版本号以不同的名称发布,而需要原始包的软件包可以继续使用你的 fork 包,因为它会替换原始包。

假设你的软件使用 original/libraryother/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

本文中的所有译文仅用于学习和交流目的,转载请务必注明文章译者、出处、和本文链接
我们的翻译工作遵照 CC 协议,如果我们的工作有侵犯到您的权益,请及时联系我们。

原文地址:https://stackoverflow.com/questions/1888...

译文地址:https://learnku.com/laravel/t/55200

本文为协同翻译文章,如您发现瑕疵请点击「改进」按钮提交优化建议
《L03 构架 API 服务器》
你将学到如 RESTFul 设计风格、PostMan 的使用、OAuth 流程,JWT 概念及使用 和 API 开发相关的进阶知识。
《L02 从零构建论坛系统》
以构建论坛项目 LaraBBS 为线索,展开对 Laravel 框架的全面学习。应用程序架构思路贴近 Laravel 框架的设计哲学。
讨论数量: 0
(= ̄ω ̄=)··· 暂无内容!

讨论应以学习和精进为目的。请勿发布不友善或者负能量的内容,与人为善,比聪明更重要!