Composer2.0 - 让PHP更加伟大!

1/ 有何新变化?

变化和改进的清单很长,如果你有兴趣阅读全部,请查看完整的变更日志。我将在这里强调几个关键点。

性能改进

我们对 Composer 和 packagist.org 之间使用的协议到依赖关系的解决,包括使用curl和约束评估优化并行下载文件,几乎所有的东西都进行了彻底的修改。这导致了速度和内存使用方面的巨大改进。差别取决于你的用例,所以虽然我已经看到一些项目中两者的改进超过 50% 的报告,但我不能给出一个确切的数字。但我相信,如果你还没有尝试 Composer 2,你一定会感到非常惊讶。

作为一个附带说明,require/remove 和部分更新现在快多了,因为Composer现在只会加载被修改的包的元数据。

初始更新+安装的时间(启动项目,空缓存)显示 Composer 2在启用 ext-curl 的情况下减少了大约 60%的时间。

架构变化与决策机制

内部重构了依赖更新的方式,对你来说,这将导致更确定性的更新。当前厂商目录的本地状态将不会再干扰更新。

在更新完成后,安装过程会自动运行,它现在会先执行所有网络绑定的操作 – 如果可能的话,还会并行执行。这将避免在安装中途发生网络错误时,给你留下一个半更新的供应商目录。

运行时特性

当 vendor/autoload.php 被初始化时,我们增加了一个平台检查步骤,它检查当前的PHP版本/扩展是否符合你的依赖关系所期望的,否则就会失败。这个步骤是默认启用的,所以请确保你阅读它以避免意外。

有一个新的类,Composer/InstalledVersions,它在每个项目中自动加载,并在运行时可用。它允许你检查你自己的项目在运行时存在哪些包/版本。

更多细节请参见运行时文档。

如果你的代码依赖于这些运行时功能,你应该在你的 composer.json 中依赖 ^2 版本的 composer-runtime-api。这是由Composer提供的一个虚拟包,以确保人们必须使用Composer 2.x 来安装你的包。

改进错误报告

因为事情并不总是按照它们应该的方式进行,所以我们确保改进了当依赖关系无法解决时显示给你的错误报告。这里很难举出具体的例子,因为有一百万种失败的方式,但希望你能注意到,现在的信息更短、更清晰、更少重复。

带有临时约束的部分更新

有时,升级或降级一个单一的包到特定的版本可能是有用的,也许是暂时测试一些东西或等待一个错误修复。例如,你现在可以运行 composer update vendor/package:1.0.* (或 1.0.12 或任何其他版本约束),以运行仅 vendor/package 的更新,使其达到与此附加约束相匹配的版本。这不会更新你的composer.json中的require,也不会将锁文件标记为过期。

如果你想添加/限制一个约束,但仍然要对所有的依赖关系进行全面更新,你可以使用 update –with vendor/package:1.0.*,这将运行与该附加约束匹配的更新。

2/ 升级有多容易?

我们的目标是让每个Composer用户都能顺利、迅速地升级。这些收益是巨大的,我们希望每个人都能从中受益。为了实现这个目标,我们做了一些事情。

Composer 2.0 仍然支持 PHP 5.3 及以上版本,就像 Composer 1.x 一样。

composer.lock 文件在不同版本之间是可以互操作的,所以你可以升级到2.0,如果需要的话,可以很容易地回滚。

大多数命令和参数保持不变,你所知道的关于Composer的大部分内容在 2.0 中都是一样的。

如果你从 1.x 开始运行composer self-update,它会警告你一个新的Composer稳定的主要版本可用,你可以使用 *composer self-update –2 *来做迁移。

如果您遇到问题,您可以在任何时候使用 composer self-update –1 回归,希望这能让大家放心地尝试新版本。

如果你是通过安装脚本自动安装Composer,并希望暂时保持在Composer 1.x上,你也可以给它传递一个-1参数,以防止它默认安装Composer 2.0。如果你这样做,请记住并争取及时升级,因为 Composer 1.x 不会维持很长时间。

3/ 向后兼容中断?

以下是升级过程中可能造成麻烦的主要内容。

插件。这可能会是大多数人的主要问题来源。插件需要更新以支持Composer 2,而其中一些插件还没有准备好。如果插件不支持 Composer 2,Composer 2 就会抱怨,无法解决依赖关系,所以不用想太多,你可以试试,看看情况如何

新的平台检查功能意味着 Composer 会检查运行时的 PHP 版本和可用的扩展,以确保它们与项目的依赖性相匹配。如果发现不匹配,自动加载器就会退出,并提供错误细节,以确保问题不会被忽略。为了避免在部署到生产中时出现问题,建议在构建或部署过程中,与生产的 PHP 进程一起运行 composer check-platform-reqs –no-dev。

仓库的优先级。如果一个包存在于优先级较高的版本库中,那么现在它在优先级较低的版本库中会被完全忽略。如果你在使用 Composer 2 时似乎丢失了包,请查看版本库优先级文档了解详情。

无效的 PSR-0 / PSR-4 配置将不再在优化的自动加载模式下自动加载,这是在 Composer 1.10 中引入的警告。这些警告大多是针对那些本来就不打算自动加载的类,所以我不指望有什么大问题,但在升级前清理这些警告是比较安全的。

如果你想了解更多,我强烈建议你阅读 UPGRADE 指南,其中有多个部分是针对最终用户、插件作者和 Composer 仓库实现者的。

4/ 下一步是什么?

我们已经没有非常详细的功能路线图了,因为 2.0 包含了大量新的好东西,但我想解释的一件重要事情是我们未来的 PHP 版本支持。

正如我在上面提到的,Composer 2.0 支持 PHP 5.3+,在这一点上,PHP 5.3+已经非常过时,使得代码在某些地方相当难以维护。我们费尽心思确保每个Composer用户都能升级到 Composer 2,但计划在未来的小版本中放弃对 EOL PHP 版本的支持。

Composer 2.1可能仍然会支持PHP 5.3,这取决于时间表和最终包含的功能,但最迟在Composer 2.2 时,我们将放弃对所有比 PHP 7.1.3 老的版本的支持。根据我们的统计,这可以让超过90%的Composer用户使用最新的版本,而对于其他停留在过时的PHP版本上的用户,我们将继续提供2.0.x或2.1.x范围内的关键错误和安全修复。

至于 Composer 1.x,现在已经差不多EOL了。如果有什么问题,它也会收到关键性的修复,但大家的目标应该是尽快迁移到2.x。

最后,我要感谢每一个做出贡献并帮助实现这一目标的人。2.0版本代表了28个人超过1100次的提交,150多个GitHub问题和pull请求,再加上每个人的测试,审查PR等。这是一个巨大的努力,大约两年前的第一次提交。

我还要感谢我们所有的私人包商客户,他们帮助资助了我们的努力,对得起我们在这一切上花费的时间。我们真诚地希望大家能欣赏这个结果!

《L04 微信小程序从零到发布》
从小程序个人账户申请开始,带你一步步进行开发一个微信小程序,直到提交微信控制台上线发布。
《L05 电商实战》
从零开发一个电商项目,功能包括电商后台、商品 & SKU 管理、购物车、订单管理、支付宝支付、微信支付、订单退款流程、优惠券等
讨论数量: 5

php是世界上最好的语言 :+1:

3个月前 评论

make php great again?

3个月前 评论
mowangjuanzi 3个月前

老外就是牛,源于他们本身的信仰与自由,对事物理性探索的态度。这点我们是比不了的。

3个月前 评论
勇敢的心 (楼主) 3个月前
勇敢的心 (楼主) 3个月前

在国外每一门语言都有狂热的爱好者,总是作者伟大的事情。

3个月前 评论

可以把原文地址在文末发一下吗

file 这一段这里前后两个 * 号让我摸不着头脑,不知道在命令行里面后面那个 * 到底要不要加上 :smile:

3个月前 评论

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