使用replace属性来防止Composer的依赖冲突
Composer 文档提供了两个基本的示例。 我将尝试解释一下:
假设你的软件使用 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」一样好。
相同的规则,只是角度略有不同:对于需要某些功能的任何其他组件,引入框架的组件是一种不错的方法。但是,如果你在软件中需要完整的框架,而另一个库又需要该框架的组件,则该框架的 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
。
这篇好文章是转载于:学新通技术网
- 版权申明: 本站部分内容来自互联网,仅供学习及演示用,请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系,请提供相关证据及您的身份证明,我们将在收到邮件后48小时内删除。
- 本站站名: 学新通技术网
- 本文地址: /boutique/detail/tanfhbcf
-
photoshop保存的图片太大微信发不了怎么办
PHP中文网 06-15 -
Android 11 保存文件到外部存储,并分享文件
Luke 10-12 -
《学习通》视频自动暂停处理方法
HelloWorld317 07-05 -
word里面弄一个表格后上面的标题会跑到下面怎么办
PHP中文网 06-20 -
photoshop扩展功能面板显示灰色怎么办
PHP中文网 06-14 -
微信公众号没有声音提示怎么办
PHP中文网 03-31 -
excel下划线不显示怎么办
PHP中文网 06-23 -
excel打印预览压线压字怎么办
PHP中文网 06-22 -
怎样阻止微信小程序自动打开
PHP中文网 06-13 -
TikTok加速器哪个好免费的TK加速器推荐
TK小达人 10-01