本文主要是介绍1024程序员节，Composer 2.0 发布了！，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
1 /有什么新功能？
变更和改进的清单很长，如果您有兴趣阅读全部内容，请查看完整的变更日志。我将在这里重点介绍一些关键点。
性能提升
从Composer和packagist.org之间使用的协议到依赖关系解析，我们几乎对所有内容进行了全面检查，包括使用curl和约束评估优化来并行下载文件。这导致速度和内存使用方面的巨大改进。差异取决于您的用例，因此尽管我看到某些项目的两个方面的改进都超过50％的报告，但我无法在上面给出确切的数字。但是我敢肯定，如果您还没有尝试过Composer 2，将会感到非常惊讶。
作为补充，require/remove和部分更新现在快得多，因为Composer现在将仅加载要更改的程序包的元数据。
架构变更和确定性
内部重构了依赖更新的方式，对您而言，这将导致确定性更高的更新。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.p2hp.com/archives/7544
这篇关于1024程序员节，Composer 2.0 发布了！的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
