React Native 核心贡献者峰会 2022
经过多年的疫情和纯线上活动，我们真的觉得是时候让 React Native 的核心贡献者们聚在一起了！
这就是为什么在 9 月初，我们聚集了一些活跃的 React Native 核心贡献者、库维护者以及 Meta 的 React Native 和 Metro 团队，举办了 2022 年核心贡献者峰会。 Callstack 在波兰弗罗茨瓦夫的总部主办了这次峰会，作为同时举行的 React Native EU 会议的一部分。
我们与 React Native 核心团队一起设计了一系列研讨会，供与会者参与。主题包括
- React Native Codegen 和 TypeScript 支持
- React Native 新架构库迁移
- React Native Monorepo
- Metro Web 和生态系统对齐
- Metro 简化的发布工作流程
我们对这两天知识共享和协作的程度印象深刻。在这篇博文中，我们想向您简要介绍一下这次聚会的成果。
React Native Codegen 和 TypeScript 支持
React Native 的 Codegen 是 React Native 新架构的基础部分。支持和改进它是我们 React Native 未来发展的首要任务之一。例如，今年早些时候，我们添加了对从 TypeScript 规范而不是 Flow 开始的泛型代码的支持。
在本次会议中，我们借此机会向新贡献者介绍了 Codegen，解释了其核心概念并描述了其工作原理。然后，我们专注于两个主要领域
1. 支持 Codegen 当前不支持的新类型。其中一个呼声很高的类型是 TypeScript 中的字符串联合类型。
一个由几个人组成的团队进入会议室来解决这个任务。他们一路遇到了并克服了一些困难，例如如何为 Codegen 运行单元测试。他们花了一些时间理解代码执行流程，然后才开始处理代码。经过几个小时的协作，他们最终得到了第一个能够识别字符串联合的原型。这次经验对于讨论设计模式以及我们未来可能想要的理想架构非常有用。
2. 改进 iOS 的自动链接，它缺少一个用例。
具体来说，当库和应用在同一个 monorepo 中时，自动链接无法很好地工作。Android 已经支持这种情况，但 iOS 却缺少。
与贡献者一起研究 Codegen 帮助我们意识到，在其代码库中工作并非易事。例如，添加对一种类型的支持需要在四个不同的地方复制粘贴相同的代码：使用 Flow 编写规范的模块、使用 TypeScript 编写规范的模块、使用 Flow 编写规范的组件以及使用 TypeScript 编写规范的组件。
这种认识促使我们创建了一个 总括任务，以寻求社区的帮助，以便改进代码库的状态，使其更易于维护。
参与度非常高：我们在 5 天内 成功分配了最初的 40 个任务。截至 10 月底，社区完成了 47 个任务，还有许多任务已准备就绪，等待合并。
这项倡议也为所有为这些改进做出贡献的人们贡献了 Hacktoberfest！
React Native 新架构库迁移
React Native 领域的热门话题是新架构。拥有支持新架构的库是 整个生态系统迁移 的关键点。因此，我们希望支持库维护者迁移到新架构。
最初，本次会议以头脑风暴的形式开始，核心贡献者有机会向 React Native 团队提出所有与新架构相关的问题。这种面对面的反馈循环对于核心贡献者澄清问题和 React Native 团队收集反馈至关重要。一些共享的反馈和关注点最终将在 React Native 0.71 中实现。
然后，我们转向尽可能多地将库实际迁移到新架构。在本次会议期间，我们启动了几个社区包的迁移过程，例如 react-native-document-picker、react-native-store-review 和 react-native-orientation。
提醒一下，如果您也在迁移库并且需要支持，请联系我们在 GitHub 上的 新架构工作组。
React Native Monorepo
今天发布新版本的 React Native 并非易事。React Native 是 NPM 上下载次数最多的包之一，我们希望确保我们的发布过程顺利。
这就是为什么我们想要重构 react-native 仓库并实施 Monorepo RFC (#480)。
在本次会议中，我们最初进行了头脑风暴，并收集了每位贡献者的意见，因为至关重要的是，我们要发展我们的仓库，以减少对下游依赖项的重大更改。
然后，我们开始在两个方面开展工作。首先，我们必须扩展我们的持续集成基础设施以支持我们的 monorepo，将 Verdaccio 添加到我们的测试基础设施中。然后，我们开始重命名和添加作用域到我们的几个包，从而产生了 6 个不同的贡献。
您可以在此 总括 issue 下跟踪此工作的状态，我们希望在不久的将来分享更多关于这项工作的信息。
Metro Web 和生态系统对齐
Metro，我们的 JavaScript 打包器，是 React Native 开发体验的基础和集成部分，我们希望确保它与 JS 生态系统的最新标准兼容。
本次会议的重点是讨论改进 Metro 的功能集，使其更好地适用于 Web 用例以及 npm 和打包器生态系统。两个主要的讨论领域
1. 采用 "exports" (包入口点) 规范
来自 Node.js 文档
采用 "exports" 规范具有很大的潜力。在本次会议中，我们讨论了如何使用 "exports" 处理 平台特定代码。考虑到许多因素，我们提出了一个相当非破坏性的 "exports" 推广计划，通过在 Metro 解析器中添加 "strict" 和 "non-strict" 模式。我们讨论了如何利用 builder-bob 帮助库创建者无摩擦地采用严格模式。
本次讨论产生了
2. Web 和打包器生态系统
Metro 团队分享了他们与 Expo 合作的进展，以及继续这种工作模式以支持即将到来的 bundle splitting 和 tree-shaking 的意图。我们再次讨论了 ES 模块支持，并考虑了潜在的未来功能，例如 Yarn PnP 和 Web 上的输出优化。我们讨论了 Metro 的核心如何与 Jest 共享逻辑和数据结构，以及更多重用的机会。
开发人员提出了关于 bundle splitting 和与第三方工具互操作性的富有洞察力的用例。这促使我们讨论 Metro 中潜在的扩展点，并改进当前的文档。
本次讨论为第二天关于简化发布工作流程的会议奠定了良好的基础。
Metro 简化的发布工作流程
如前所述，发布 React Native 并非易事。
当我们需要发布 React Native、React Native CLI 和 Metro 时，事情变得更加困难。这些工具彼此关联，因为 React Native 和 CLI 都依赖于 Metro。当任何一个包发布新版本时，都会产生一些摩擦。
目前，我们通过直接沟通和同步发布来管理这个问题，但仍有改进空间。
在本次会议中，我们重新考虑了 React Native、Metro 和 CLI 之间的依赖关系。我们发现，在 “Lean Core” 工作 期间，当我们从 React Native 中提取 CLI 时，一些设计决策如何使这两个项目在功能上相互依赖，并且在努力中重复了一些功能。当时的决策是有道理的，并使 CLI 团队能够比以往更快地迭代。
现在是时候重新审视它们，并利用两个团队的经验来找出解决之道了。结果，Metro 团队将接管 @react-native-community/cli-plugin-metro 的开发，暂时将其移回 React Native 的核心，然后很可能移至 Metro monorepo。
最大的收获，除了在白板上绘制包之间依赖关系的三小时之外，就是 CLI 和 Metro 团队交流了他们的问题、经验和计划，从而更好地了解了彼此。
如果没有真正见面，我们将无法达到这种程度的合作。
我们仍然对几天时间一起度过几个小时所产生的知识共享和思想交叉传播的程度感到印象深刻。在本次峰会上，我们为有助于我们改进和重塑 React Native 生态系统的倡议播下了种子。
我们要再次感谢 Callstack 主办我们，并感谢所有参与者加入我们参加 2022 年核心贡献者峰会。
如果您有兴趣加入 React Native 的开发，请务必加入我们的开放倡议并阅读我们网站上的 贡献指南。我们希望将来也能与您面对面交流！