Packagist 和 PHP 生态系统

*本篇文章是由著名的 PHP 开源*开发者* Graham Campbell 撰写的客座文章，也是他关于使用 Composer 最佳实践的系列文章的第二篇。请阅读第一篇博客文章[使用 Composer 构建可维护的 PHP 应用程序](https://blog.bugsnag.com/best-practices-using-composer/?utm_source=laravelnews&utm_medium=cpc&utm_content=packagist-php&utm_campaign=laravel&utm_term=201706).*

在我们上一篇博文中，我们了解了 Composer 的基础知识，但忽略了它实际查找软件包的位置，以及如何发布自己的软件包。在这篇博文中，我们将详细介绍这些内容，以及在应用程序中使用 Composer 时的一些安全注意事项。

#什么是 Packagist？

Packagist 是 Composer 的主要软件包仓库。您可以在这里发布您的软件包，也可以查看其他人的软件包。Composer 默认情况下会使用 Packagist 来查找软件包，但是，高级用户可以根据需要自定义此设置。您可能需要自定义此设置的原因之一是使用私有软件包。有关更多详细信息，请参阅Composer 文档中的仓库部分.

#通过 Packagist 发布您的软件包

好的，您一直在开发新的软件包，现在您想发布它，这样不仅您可以使用它，而且其他人也可以查看您的作品！为了发布您的软件包，请访问 https://packagist.org.cn/packages/submit，并提供您代码的 URL，无论是 GitHub、Bitbucket、Gitlab 还是其他平台。

幸运的是，发布软件包版本非常简单。您只需要使用 git 创建一个标签，就可以了。您不应该在您的 composer.json 文件中设置版本字段。

想要搜索类似的软件包，并查看您自己的列表？您可以探索所有公开可用的软件包 Packagist 网站.

#软件包许可

许可字段是可选的，但最好设置它，以便人们知道他们是否以及如何使用您的软件包。常见的错误是在这里键入人类可读的许可证名称，而不是实际的“许可证标识符”。在这里，您可以找到可能的许可证列表。如果您的代码使用专有许可证，使用“专有”作为许可证标识符也是允许的。一些常见的许可证包括 Apache-2.0、BSD-2-Clause、BSD-3-Clause、GPL-2.0、GPL-3.0 和 MIT。

Composer 实际上可以告诉您所有依赖项的许可证。只需运行 licenses 命令

composer licenses

这将输出类似以下内容

#开发版本

因此，您正在为您的软件包开发一个很棒的新功能，并且您想对其进行测试。但有一个问题：您希望能够加载您的更改，而无需标记版本，因为很明显，您还没有准备好发布版本。您可以使用几种方法

1. 在您的软件包 composer.json 中添加一个分支别名，
2. 在您的应用程序 composer.json 中直接引用分支名称。

#分支别名

这些自动意味着您可以将分支与dev软件包版本相关联！

想象一下，您正在 master 分支上进行 2.0.0 版本的发布，您希望能够在标记版本之前安装它。一个好的方法是将 master 分支与版本“2.0.x-dev”关联起来。

在您的应用程序中，您可以使用版本约束“2.0.*@dev”或类似的约束来访问您的 2.0 开发版本。

事实上，Composer 足够聪明，可以实际查看分支名称，并确定它与哪个版本相关联。例如，如果您将分支命名为“2.0”，那么 Composer 将将其视为代表最新的“2.0.x-dev”版本。

最后，需要注意的是，您实际上可以通过在您的应用程序 composer.json 文件中设置以下内容来避免在您的依赖项中指定稳定性

这将告诉 Composer，如果您需要，它可以将“^2.0”或“2.0.*”解析为开发版本，但如果您能解析稳定版本，它会更倾向于解析稳定版本。

#直接引用分支名称

如前所述，访问新代码的另一种方法是直接使用分支名称作为版本。当您正在开发一项特定新功能，而不是希望测试一些合并的更改时，这非常有用。要安装名为“new-feature”的分支，您将需要版本约束“dev-new-feature”。

#安全注意事项

从我之前的博文中可以回想起，Composer 在您的仓库中留下了一个“composer.lock”文件。对于应用程序来说，提交此文件非常有用，因为它将您的依赖项锁定在已知状态，让您可以精细控制与应用程序一起部署的软件包。

特别是，它将允许您防止依赖项发生意外的破坏性更改或引入错误。当然，这些可能会对应用程序的安全性产生影响。

我们实际上可以比这更进一步，并检查我们的一组已解析的依赖项是否存在已知的安全问题。SensioLabs 提供一项服务，用于检查您的 composer.lock 文件是否存在已知的安全漏洞

用于检查的数据库在 GitHub 上公开可用，地址为

https://github.com/FriendsOfPHP/security-advisories.

最后，也可以注册一个私有软件包仓库，并通过它代理 packagist.org，为此，您可以使用付费服务/解决方案。

#了解新版本

我们已经看到了为跟踪安全问题而提供的功能和工具。但是，这些工具不会显示您的软件包版本是否不再受作者支持，也不会显示是否存在您版本的约束限制您安装的更新版本。

幸运的是，Composer 提供了一个简单的命令，您可以运行该命令，它会显示您已安装的软件包版本以及最新版本。如果我在几周前安装了依赖项的示例仓库中运行 composer outdated，我们已经可以看到有可用的更新

主要更新以红色显示，次要更新以黄色显示。通常可以安全地立即升级到次要版本；但是，您始终应该注意了解每个依赖项的版本控制策略，并且您可能还想自己查看更改。

您可以运行 composer update 以更新到您的版本约束允许的最新依赖项，也可以修改您的版本约束以访问更新的版本。

最后，需要注意的是，您可以使用“composer self-update”更新 Composer 本身。

#结论

我们已经看到了 Composer 提供的更强大的功能，以及如何在 Packagist 上发布软件包。现在，您可以放心地发布您的应用程序，因为您知道您的依赖项是最新的，并且没有已知的安全漏洞。

了解更多关于使用 Bugsnag 监控和报告 PHP 应用程序错误。