在上一部分中，我们完成了 Laravel 翻译包的构建。现在，我们可以开始考虑将其发布到全球了。然而，在发布之前，我们还需要采取一些重要的步骤。
文档
为包的用户提供清晰的说明非常重要，说明如何使用该包。文档的范围将取决于您正在创建的包的大小和复杂性。至少，我建议在项目的根目录中添加一个 README.md 文件，详细说明如何安装和开始使用该项目。您可以在这里查看 Laravel 翻译包的 README.md 这里.
良好的文档将降低用户的入门门槛，这意味着他们更有可能使用它并向他人推荐它。它还有助于减少添加到您的仓库中的问题数量，因为用户更有可能找到他们问题的答案。
我再怎么强调良好文档的重要性也不为过。如果您由于缺少文档而遇到问题，请务必添加它，以防止问题再次出现。
贡献指南
发布您的包后，您很可能会得到热心的社区成员的帮助，他们希望帮助您让该包变得更好。这可能包括修复已知问题，添加文档，甚至添加全新的功能。
这些贡献将以拉取请求的形式出现，您需要审核这些请求，以决定是否接受或拒绝，或者告知贡献者您希望在合并之前进行的更改。
为了让您的工作更轻松，最好添加一个 CONTRIBUTING.md 文件，其中概述了贡献者应遵循的一组指南。
这可能包括要采用的代码风格、分支和 git 策略、测试要求以及您希望贡献者遵循的其他任何内容。
问题模板
我最近了解到 GitHub 上的问题模板，它为您提供了一种很好的方法，可以向用户概述您在他们向您的项目提交问题时需要从他们那里获得的信息。
默认情况下，GitHub 支持错误报告和功能请求，但您可以随意添加自己的自定义模板。
我在 Laravel 翻译项目中应用了默认选项设置。现在，当用户尝试提出问题时，他们需要选择是错误报告还是新功能请求。
当他们选择其中一个选项时，他们会看到一个模板，其中详细说明了他们应该提供的信息。
对于错误报告，这包括重现问题的步骤，以及屏幕截图、受影响的浏览器和操作系统等详细信息。
对于功能请求，它更多地是关于功能是什么以及为什么需要它。
我并不建议您必须使用此功能。但是，让您拥有了解问题所需的所有信息，而无需与用户进行冗长的来回对话，总是很有帮助的。
许可证
开源包需要一个开源许可证来保护其维护者、贡献者和用户。
有许多不同的许可证类型可供选择。最终选择哪一个将取决于您希望如何使用、修改和共享您的包。
GitHub 创建了一个网站来帮助开源维护者选择开源许可证。他们承认，这不是一个完全全面的目录，但它突出了最有可能适合您的目录，并指引您了解其他目录，如果他们的推荐不足够的话。
持续集成
有大量的持续集成工具可以帮助您完成一些事情，例如确保您的代码在测试失败时不会被部署、自动修复代码风格问题、衡量您的代码质量，以及其他许多事情。
这些工具直接与 GitHub 集成，并且可以在将代码提交到仓库时自动触发运行。
这意味着，当贡献者向项目发出新的拉取请求时，您可以在查看代码之前，就已经了解它的整体质量。
更重要的是，大多数这些工具都提供针对开源项目的免费层级。
以下是一些我个人推荐的工具。
Travis CI
当代码提交到您的仓库时，GitHub 会触发 Travis 构建和测试您的代码。您将在几分钟内收到通知，告知您一切是否正常。它也适用于拉取请求，因此您可以查看贡献者是否在您的代码库中添加了任何问题。
Scrutinizer
Scrutinizer 将分析您的代码，查看您是否使用了任何不安全的语言特性。它还具有代码浏览功能，在查看代码时提供类似 IDE 的功能。
StyleCI
StyleCI 允许您定义您喜欢的代码风格。当代码提交到仓库时，它会自动根据您的指南检查代码是否存在错误，并自动修复这些错误，通过提供一个包含建议更改的拉取请求到仓库。这使您可以放心，您的代码永远不会违反项目的代码风格指南。
集成通常非常简单，包括登录服务、与 GitHub 集成，以及在项目的根目录中添加一个配置文件。一旦设置好，它们将在将代码提交到仓库时按需运行。
有了所有这些准备工作，我们几乎可以上线了。在下一篇文章中，我会向您介绍如何让您的包可供其他人使用。如往常一样，如果您有任何问题，请在 Twitter 上与我联系。
