如果你还不知道 composer,请前往composer使用教程栏目然后开始阅读吧。
我曾见过许多人被他们使用的 composer 包之间依赖的约束问题所困扰。希望这篇文章能指出某些问题的原因,并提供避免这些问题的方法。我会从最糟的情景入手,并一步步改进约束。
全能的星号:*
Composer 有一个依赖解析器,所以它能够自动的找出我想要的,对吗?错。
用 *
声明一个版本约束可能是最糟糕的做法之一。因为你绝对无法控制你会得到什么。它可能是 任何 匹配 minimum-stability
和其它约束的版本。
基本上你就相当于在和 Composer 玩一个 俄罗斯轮盘赌 游戏,最终你会被它伤害到。然后你就可能会责怪这个工具太令你失望了。
如果你继续粗心大意,请最起码依赖最新的开发版本,通常被标记为 dev-master
。
写死的分支名称
所以你现在在使用 dev-master
。问题在于,dev-master
所指向的代码可能会更改。至少,你获取的总是不稳定的包(从 composer 所表征的稳定性标志来看不稳定)。然而,更大的问题在于,dev-master
的意义可能随时会变。
比方说,现在它所表示的是最新的 1.0 开发版本。当开发者说他们要开始开发 1.1 版本的时候,dev-master
这个分支名字不再指向 1.0 分支,它开始指向最新的 1.1 开发分支。
除非你紧密关注着该库的开发,否则,直到你运行了 composer update
命令时,问题才会显示在你面前,然后毁了你一整天。因此,直接引用分支的名称并不是一个可持续的解决方案。幸运的是,在别名的问题上,composer
可以提供帮助。
分支别名
分支别名作为一个属性,包维护者可以将其放到他们的 composer.json
里面,允许这些分支名称映射到版本上。
像 1.0 , 2.1 等等分支名称并不是必须的, Composer
已经对这些进行了处理。
但是像 master
这样的分支名称会产生一个名为 dev-master
的版本,你一定要给它别名。 Composer
文档里面有 一个不错的关于别名的文章 ,里面解释了如何定义分支别名:
{ "extra": { "branch-alias": { "dev-master": "1.0.x-dev" } } }
dev-master
版本会映射到一个 1.0.x-dev
的别名上,
这基本上意味着你可以用一个 1.0.*@dev
的约束来要求包。这样的好处是 1.0 的含义会被定义,且不会改变。 它也将使切换到稳定版本更容易。
分支别名的警告需要包维护者将它们放入。如果使用的是没有分支别名的库,则向它们发送一个上拉请求,将上面的 extra
部分添加到它们的 composer.json
中。
稳定版本
1.0.*@dev
这个约束已经很不错了。但问题是到目前为止,仍然还没有一个稳定的版本。除了你仍然运行着一个不稳定的版本这个事实之外,你的代码并没有什么问题。
但是如果别人的项目依赖了你的包,那么你的用户需要明确地使用 @dev
标识来允许 Composer 安装不稳定的版本,或者干脆降低项目 minimum-stability
的等级,这意味着他们将获得 所有依赖包 的不稳定版本。
避免开发版本不稳定性的最好方法就是打上 release 标签(指发布稳定版本)。 如果你正在使用一个没有打上 release
标签的库,提醒它的维护者直到打上标签。现在就做!
作为 Composer 社区的一份子,我们要有责任心。 我们必须发布稳定的版本,并且应该维护好 CHANGELOG (更新日志)。 这很不容易,但是这将让整个生态系统发生巨大的改变。记住,如实地、 语义化 地来打标签。
当你发布了一个稳定的版本,你就能去掉 @dev
标识并且将你的约束改为 1.0.*
。
下一个重大版本
如果你所依赖的包的每一个发布节点都坚持遵守语义化版本的规则,并且严格向后兼容,那么你就可以逐渐提高约束。
现在 1.0.*
版本有一些潜在的兼容性问题,并很快发布了 1.1
版本。如果你的约束是 1.0
,但是别人需要 1.1
版本的新特性(还记得向后兼容吗?), 他们就不能安装 1.1
版本。所以你需要重写你的约束,比如: 1.*
。
好极了,除非你开始依赖 1.1
版本的新特性,否则你不必修改约束,它将会仍然匹配 1.0
这个没有新特性的版本。
接着,你修改约束为 >=1.1,<2.0
,但这种写法比较麻烦。使用波浪线操作符能允许你用简洁的方式表示上面的表达式: ~1.1
。这表示任意在 1.1 以上的 1.* 版本。现在你知道了,鼓励语义化版本是为了使用波浪线操作符,并且可以最大化的封装兼容性。
TLDR
使用 branch-alias
。
标签发布,使发布更可靠和 符合语义.
使用 ~
运算符。
以上是你必须知道的 Composer 版本约束的详细内容。更多信息请关注PHP中文网其他相关文章!

使用Composer结合AI可以实现自动化任务。1.Composer通过配置文件管理依赖,AI可优化版本选择。2.在实际应用中,AI可用于自动化依赖管理、测试和部署。3.性能优化包括依赖加载和缓存策略。4.需注意版本冲突和AI误判等问题。通过这些方法,AI能提升工作效率和智能化程度。

ComposerwithAI是利用AI提升编程体验的工具。1)它通过分析代码结构、语法和模式,提供实时建议和错误修复。2)高级功能包括代码重构、性能优化和安全性检查。3)使用时可调整配置、提供反馈和结合其他工具来解决常见问题。

Composer是PHP的依赖管理工具,用于管理项目所需的库和包。1)它通过composer.json文件定义依赖,2)使用命令行工具进行安装和更新,3)自动化依赖管理过程,提高开发效率,4)支持高级功能如动态添加依赖和自动加载,5)通过composer.lock文件确保团队环境一致性。

Composer是PHP的依赖管理工具,通过composer.json和composer.lock文件管理项目依赖。1.创建composer.json文件并运行composerinstall安装依赖。2.使用composerrequire添加新依赖。3.配置autoload实现类自动加载。4.使用composerdiagnose检查项目健康状况。5.优化依赖管理:指定包名更新,使用composerdump-autoload-o优化自动加载器,生产环境使用composerinstall--no-d

AI与Composer结合可提升PHP开发效率和安全性。具体体现在:1.依赖解析和优化:AI可预测依赖关系,减少冲突。2.自动化安全检查:AI能识别安全漏洞,建议更新。3.代码生成和优化:AI能自动生成和优化相关代码。

vProcesserazrabotkiveb被固定,мнелостольностьстьс粹馏标д都LeavallySumballanceFriablanceFaumDoptoMatification,Čtookazalovnetakprosto,kakaožidal.posenesko

在开发一个基于Symfony的应用程序时,我遇到了一个棘手的问题:如何有效地验证JSON数据格式。最初,我尝试使用手动编写的验证代码,但这不仅复杂,而且容易出错。经过一番探索,我发现了一个名为ptyhard/json-schema-bundle的Composer包,它为我的项目带来了极大的便利和效率。

在开发一个电商网站时,我遇到了一个棘手的问题:如何为用户提供个性化的商品推荐。最初,我尝试了一些简单的推荐算法,但效果并不理想,用户的满意度也因此受到影响。为了提升推荐系统的精度和效率,我决定采用更专业的解决方案。最终,我通过Composer安装了andres-montanez/recommendations-bundle,这不仅解决了我的问题,还大大提升了推荐系统的性能。可以通过一下地址学习composer:学习地址


热AI工具

Undresser.AI Undress
人工智能驱动的应用程序,用于创建逼真的裸体照片

AI Clothes Remover
用于从照片中去除衣服的在线人工智能工具。

Undress AI Tool
免费脱衣服图片

Clothoff.io
AI脱衣机

Video Face Swap
使用我们完全免费的人工智能换脸工具轻松在任何视频中换脸!

热门文章

热工具

SublimeText3汉化版
中文版,非常好用

Dreamweaver CS6
视觉化网页开发工具

安全考试浏览器
Safe Exam Browser是一个安全的浏览器环境,用于安全地进行在线考试。该软件将任何计算机变成一个安全的工作站。它控制对任何实用工具的访问,并防止学生使用未经授权的资源。

螳螂BT
Mantis是一个易于部署的基于Web的缺陷跟踪工具,用于帮助产品缺陷跟踪。它需要PHP、MySQL和一个Web服务器。请查看我们的演示和托管服务。

SublimeText3 英文版
推荐:为Win版本,支持代码提示!