一. 有什么新功能？

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

性能提升

从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.*它将使用该附加约束来运行更新。

二. 升级有多容易？

我们的目标是使每位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的维护时间不会很长。

三. 向后兼容性中断？

以下是可能在升级过程中引起麻烦的主要因素：

• 插件：对于大多数人来说，这可能将是问题的主要根源。需要更新插件以支持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仓库实现者多个部分。

四.接下来是什么？

我们没有一个非常详细的功能路线图，因为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/ 中文：https://blog.p2hp.com/archives/7544