Composer 2.0新特性

时间：2021-9-16 作者：smarteng 分类： PHP相关

一、有什么新功能？

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

性能提升

从 Composer 和 packagist.org 之间使用的协议到依赖关系解析，我们几乎对所有内容进行了全面检查，包括使用 curl 来并行下载文件和优化约束评估。这带来了速度和内存使用方面的巨大改进。差异取决于您的使用方式，因此尽管我看到这两项改进在某些项目上都有超过 50％的提升，但我无法在这上面给出确切的数字。但是我敢肯定，如果您还没有尝试过 Composer 2，将会感到非常惊讶。
补充一句， require / remove 和部分更新（partial updates ）现在变得快多了，因为 Composer 现在将仅加载需要更改的程序包的元数据。

在启用 ext-curl 的环境下，Composer 2 在初始更新和安装 (bootstrapped project, empty cache) 的总时间减少了大约 60% 。

架构变更和确定性

重构了依赖更新的内部工作方式，对您而言，这将导致确定性更高的更新。vendor 目录的当前本地状态将不再干扰更新。
更新完成后，安装过程将自动运行，并且现在将首先执行所有网络相关操作，并在可能的情况下并行执行。如果在安装过程中发生网络错误，这将避免为您留下一个部分更新的 vendor 目录。

运行时功能

当 vendor/autoload.php 初始化时，我们添加了一个平台检查的步骤，该步骤检查当前 PHP 版本以及 PHP 扩展模块是否与依赖项所期望的相匹配，如不匹配则将导致失败。默认情况下启用此功能，因此请确保您已仔细阅读它，以免出现意外。
添加了一个新类 Composer\InstalledVersions ，它会在每个项目中自动加载，并在运行时可用。它使您可以检查自己的项目在运行时已经存在了哪些程序包及其版本。
有关更多详细信息，请参见运行时文档。
如果您的代码依赖于任何这些运行时功能，则应该在 composer.json 文件中添加依赖项 "composer-runtime-api": "^2.0" 。这是 Composer 提供的虚拟软件包（virtual package ），可确保使用者必须使用 Composer 2.x 来安装您的软件包。

改进错误报告

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

具有临时约束的部分更新

有时需要将单个软件包升级或降级到某个特定版本，可能是暂时测试某些内容或等待错误修复。现在您可以运行类似 composer update vendor/package:1.0.* 的命令（或 1.0.12 等任何版本约束），以达到仅更新 vendor/package 到指定版本的目的。这不会在 composer.json 文件中更新您的依赖，也不会将锁文件标记为过期。
如果要添加或限制版本约束，但仍要对所有依赖项进行完整的更新，则可以使用 update --with vendor/package:1.0.* 命令，它将遵照该附加版本约束并执行更新。

升级的难易程度

我们的目标是使每位 Composer 用户都能顺利、迅速地升级。您所获得的将是巨大的，我们希望每个人都能从中受益。为了实现这一点，我们做了几件事：

Composer 2.0 仍支持 PHP 5.3 及更高版本，非常类似于 Composer 1.x
composer.lock 文件在新旧 Composer 版本之间可以互操作，因此您可以升级到 2.0，并在需要时轻松回滚。
大多数命令和参数保持不变，并且您使用 Composer 的技能在 2.0 中仍然是正确的。

如果 composer self-update 命令是使用 1.x 版本运行的，Composer 将警告您有新的、稳定的 Composer 主版本可用，您可以运行 composer self-update --2 命令来迁移到新版本。
遇到问题时，您可以随时使用 composer self-update --1 命令返回到旧版本上。希望这将使每个人都可以安心地尝试 Composer 新版本。
如果要通过安装程序脚本自动安装 Composer，并且希望暂时保留在 Composer 1.x 版本上，则还可以向其传递一个 --1 参数，以防止其默认情况下安装 Composer 2.0。如果这样做，请记得及时升级，因为 Composer 1.x 的维护时间不会很长。

向后兼容性中断了吗？

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

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

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

接下来的计划？

我们没有一个非常详细的功能路线图，因为 2.0 版本包含了许多新功能，但是我想解释的一件重要事情是我们对 PHP 版本的支持。
正如我上面提到的，Composer 2.0 支持PHP 5.3+，这在现在已经非常过时的 PHP 版本了，并且使得代码在某些地方很难进行维护。我们努力确保每个 Composer 用户都可以升级到 Composer 2，但计划是在将来的次要版本中放弃对 EOL PHP（即生命期结束的 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 多个 commit，150 多个 GitHub issue和 PR，以及测试、审查 PR 的所有人等。从两年前的第一次 commit 到现在，大家付出了巨大的努力。
我还要感谢所有 Private Packagist 的客户，他们为这项工作提供了资金，并为我们提供了花在所有这些方面的时间。我们衷心希望每个人都会喜欢这个最终的结果！

标签: composer

上一篇:人生难题的解法可能就在你的身边下一篇:linux 统计代码行数