开源路线图

今年，React Native 团队专注于 React Native 的大规模重新架构。正如 Sophie 在她的React Native 现状文章中提到的，我们已经制定了一个计划，以更好地支持 Facebook 之外不断壮大的 React Native 用户和贡献者群体。现在是时候分享我们一直在努力的更多细节了。在此之前，我想阐述一下我们对开源 React Native 的长期愿景。

我们对 React Native 的愿景是……

• 健康的 GitHub 仓库。 问题和拉取请求在合理的时间内得到处理。
  • 提高测试覆盖率。
  • 从 Facebook 代码仓库同步出来的提交不应破坏开源测试。
  • 更大规模有意义的社区贡献。
• 稳定的 API， 使与开源依赖的接口更加容易。
  • Facebook 使用与开源相同的公共 API
  • 遵循语义化版本控制的 React Native 发布。
• 充满活力的生态系统。 由社区维护的高质量 ViewManagers、原生模块和多平台支持。
• 出色的文档。 专注于帮助用户创建高质量体验，以及提供最新的 API 参考文档。

我们已经确定了以下重点领域，以帮助我们实现这一愿景。

✂️ 精简核心

我们的目标是通过移除非核心和未使用的组件来缩小 React Native 的表面积。我们将非核心组件转移给社区，以便其更快地发展。缩小的表面积将使管理对 React Native 的贡献变得更容易。

WebView 是我们转移给社区的组件示例。我们正在制定一个工作流程，允许内部团队在我们将这些组件从仓库中移除后继续使用它们。我们已经确定了数十个其他组件，将把所有权移交给社区。

🎁 内部开源和 🛠更新工具

Facebook 产品团队的 React Native 开发体验可能与开源社区大相径庭。开源社区中流行的工具在 Facebook 内部可能不被使用。可能存在实现相同目的的内部工具。在某些情况下，Facebook 团队已经习惯了在 Facebook 之外不存在的工具。当我们开源即将到来的架构工作时，这些差异可能会带来挑战。

我们将致力于发布一些内部工具。我们还将改进对开源社区中流行工具的支持。以下是我们将要解决的项目的不完全列表：

• 开源 JSI 并使社区能够引入自己的 JavaScript VM，取代 RN 最初版本中现有的 JavaScriptCore。我们将在未来的文章中介绍 JSI 是什么，与此同时，您可以从Parashuram 在 React Conf 上的演讲中了解更多关于 JSI 的信息。
• 支持 Android 上的 64 位库。
• 在新架构下启用调试。
• 改进对 CocoaPods、Gradle、Maven 和新 Xcode 构建系统的支持。

✅ 测试基础设施

当 Facebook 工程师发布代码时，如果通过所有测试，则认为可以安全地部署。这些测试可以识别更改是否可能破坏我们自己的 React Native 界面。然而，Facebook 使用 React Native 的方式存在差异。这导致我们可能在不知不觉中破坏了开源的 React Native。

我们将加强内部测试，确保它们在尽可能接近开源的环境中运行。这将有助于防止破坏这些测试的代码进入开源。我们还将致力于基础设施建设，以更好地测试 GitHub 上的核心仓库，使未来的拉取请求能够轻松地包含测试。

结合缩小的表面积，这将允许贡献者更快、更有信心地合并拉取请求。

📜 公共 API

Facebook 将通过公共 API 使用 React Native，与开源方式相同，以减少无意中引入的破坏性变更。我们已经开始转换内部调用点来解决这个问题。我们的目标是趋向于一个稳定的公共 API，从而在 1.0 版本中采用语义化版本控制。

📣 沟通

React Native 是按贡献者数量计算的 GitHub 上顶级开源项目之一。这让我们非常高兴，我们希望保持这种势头。我们将继续致力于能够吸引更多贡献者的举措，例如增加透明度和开放讨论。文档是 React Native 新手会遇到的第一件事，但它一直不是优先事项。我们希望解决这个问题，首先是恢复自动生成的 API 参考文档，创建更多专注于创建高质量用户体验的内容，并改进我们的发布说明。

时间线

我们计划在接下来的一年左右时间里落地这些项目。其中一些工作已经在进行中，例如JSI 已在开源中落地。其他一些工作则需要更长的时间才能完成，例如缩小表面积。我们将尽最大努力让社区了解我们的进展。请加入我们的讨论和提案仓库，这是 React Native 社区的一项倡议，它促成了本路线图中讨论的几项倡议的诞生。