Composer 升级到 2.0 版本，有哪些功能是你必知的？

1/ 有什么新特性?

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

性能提升

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

附带说明一下，因为 Composer 现在仅仅加载要更改的软件包的数据，所以 require /remove 和部分更新现在要快得多。

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

架构变更和稳定性

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

运行时功能

我们在初始化 vendor/autoload.php 时添加了一个 platform-check step  ，它会检查当前的PHP版本（以及可选的扩展名） ）匹配您的依赖项所期望的内容，否则将导致失败。 默认情况下启用此功能，因此请确保您已仔细阅读它，以免出现意外。

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

查看 runtime docs 了解更多信息.

如果您的代码依赖于这些运行时功能中的任何一个，则应在 composer.json 中要求使用 "composer-runtime-api": "^2.0"。 这是 Composer 提供的虚拟软件包，可确保人们必须使用 Composer 2.x 来安装您的软件包。

错误报告改进

由于事情并不一定总是如预期的那样进行，因此，当无法解决依赖关系时，我们确保改进显示给您的错误报告。 这里很难给出具体的例子，因为有上百万种方法可能会失败，但是您希望您会注意到消息现在变得更短，更清晰并且重复性更低。

具有临时约束的部分更新

有时将单个软件包升级或降级到特定版本可能很有用，可能是暂时测试某些内容或等待错误修复。 现在，您可以运行composer update vendor/package:1.0.*（或1.0.12或任何其他版本约束），以仅将vendor/package 更新运行到与该附加约束匹配的版本。 这不会在 composer.json 中更新您的需求，也不会将锁定文件标记为过期。

如果要添加/限制约束但仍对所有依赖项进行完整更新，则可以使用 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 的维护时间不会很长。

看到 Command "self-update" is not defined.报错？ 如果通过 OS 软件包管理器安装了Composer，则 self-update 命令可能不可用。 使用 which composer 命令查找其路径（例如，/usr/bin/composer），然后运行安装脚本 添加 --install-dir /usr/bin --filename composer （调整安装目录以匹配您的路径）到 php composer-setup.php 行。

3/ 向后兼容性中断？

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

• Plugins: 对于大多数人来说，这可能将是问题的主要根源。 需要更新插件以支持Composer 2，但其中一些尚未准备好。 如果插件不支持Composer 2，则Composer 2将报错无法解决依赖关系，因此无需过多考虑，您可以尝试一下并看看它如何运行。
• 新的平台检查功能意味着 Composer 会检查运行时PHP版本和（可选）可用的扩展以确保它们与项目依赖项匹配。 如果发现不匹配，自动安装器将退出并显示错误详细信息，以确保不会忽略问题。 为了避免在部署到生产环境时出现问题，建议在生产或PHP流程的构建或部署过程中运行 composer check-platform-reqs。
• 存储库优先级：如果某个包存在于较高优先级的存储库中，则现在将在较低优先级的存储库中将其完全忽略。 如果您在使用Composer 2时似乎缺少软件包，请参阅存储库优先级文档了解详细信息。
• 无效的PSR-0 / PSR-4配置，根据 Composer 1.10 中引入的警告，将不再以优化的自动加载器模式自动加载。 大多数情况下，这些警告是针对不会自动加载的类，因此我认为不会出现重大问题，但是在升级之前清理它们更安全。

如果您想了解更多信息，我强烈建议您阅读[升级指南ub.com/composer/composer/blob/master/UPGRADE-2.0.md) ，该指南针对最终用户，插件作者有多个部分 和 omposer 储库实现者。

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问题和请求，以及测试它，审查PR的所有人等。两年前的第一次提交付出了巨大的努力。

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

本文中的所有译文仅用于学习和交流目的，转载请务必注明文章译者、出处、和本文链接
我们的翻译工作遵照 CC 协议，如果我们的工作有侵犯到您的权益，请及时联系我们。

原文地址：https://blog.packagist.com/composer-2-0-...

译文地址：https://learnku.com/laravel/t/53108