Composer 2.0 发布了!

1 /有什么新功能?

变更和改进的清单很长,如果您有兴趣阅读全部内容,请查看完整的变更日志。我将在这里重点介绍一些关键点。

性能提升

从Composer和packagist.org之间使用的协议到依赖关系解析,我们几乎对所有内容进行了全面检查,包括使用curl和约束评估优化来并行下载文件。这导致速度和内存使用方面的巨大改进。差异取决于您的用例,因此尽管我看到某些项目的两个方面的改进都超过50%的报告,但我无法在上面给出确切的数字。但是我敢肯定,如果您还没有尝试过Composer 2,将会感到非常惊讶。

作为补充,require/remove和部分更新现在快得多,因为Composer现在将仅加载要更改的程序包的元数据。

启用ext-curl的初始更新+安装时间(引导项目,空缓存)显示Composer 2使用的时间减少了大约60%

架构变更和确定性

内部重构了依赖更新的方式,对您而言,这将导致确定性更高的更新。vendor目录的当前本地状态将不再干扰更新。

更新完成后,安装过程将自动运行,现在它将首先执行所有网络绑定操作 -如果可能将并行执行。如果网络错误在安装中途发生,这样可以避免留下半更新的vendor目录。

运行时功能

当vendor/autoload.php 初始化时,我们添加了一个平台检查步骤,该步骤检查当前 PHP 版本/扩展程序与依赖项的预期匹配,否则将导致失败(fails hard otherwise)。

有一个新类Composer\InstalledVersions会在每个项目中自动加载,并在运行时可用。它使您可以检查自己的项目运行时存在哪些程序包/版本。

有关更多详细信息,请参见运行时文档

如果您的代码依赖于任何这些运行时功能,则应require"composer-runtime-api": "^2.0"在composer.json中。这是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配置将不再以optimized-autoloader模式自动加载,根据Composer 1.10中引入的警告。大多数情况下,这些警告是针对不会自动加载的类,因此我认为不会出现重大问题,但是在升级之前清理它们更安全。

如果您想了解更多信息,我强烈建议您阅读升级指南,该指南有针对最终用户,插件作者和Composer仓库实现者多个部分。

4 /接下来是什么?

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

正如我上面提到的,Composer 2.0支持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,现在已经或多或少地处于寿命终止状态。如果有任何问题,它也会收到重要的修复程序,但每个人的目标应该是尽快迁移到2.x。

最后,我要感谢所有为实现这一目标做出贡献和帮助的人。2.0版本代表来自28个人的1100多个提交,150多个GitHub issues和pull requests,以及所有测试它、审查PR的人员,等等。从两年前的第一次提交已付出了巨大的努力。

我还要感谢所有Private Packagist客户,他们为这项工作提供了资金,并为我们提供了花在所有这些方面的时间。我们衷心希望每个人都会感激这个成果!

原文https://blog.packagist.com/composer-2-0-is-now-available/

Composer 2.0 发布了!
标签: