React Native 核心贡献者峰会 2022
在经历了多年的疫情和纯线上活动之后，我们真的觉得是时候将 React Native 的核心贡献者们聚集在一起了！
因此在九月初，我们聚集了一些活跃的 React Native 核心贡献者、库维护者以及 Meta 的 React Native 和 Metro 团队成员，举办了 **2022 年核心贡献者峰会**。 Callstack 在他们位于波兰弗罗茨瓦夫的总部主办了本次峰会，作为同期举办的 React Native EU 会议的一部分。
我们与 React Native 核心团队一起，设计了一系列研讨会，供与会者参与。主题包括
- React Native 代码生成与 TypeScript 支持
- React Native 全新架构库迁移
- React Native Monorepo
- Metro Web 和生态系统对齐
- Metro 简化发布工作流程
这两天知识共享和协作的程度给我们留下了深刻的印象。在这篇博文中，我们想让您先睹为快，了解本次聚会的成果。
React Native 代码生成与 TypeScript 支持
React Native 的代码生成是 React Native 全新架构的基础部分。支持和改进它是我们 React Native 未来发展的首要任务之一。例如，今年早些时候，我们添加了对从 TypeScript 规范而不是 Flow 开始生成泛型代码的支持。
在本次会议中，我们借此机会让新的贡献者了解代码生成，解释其核心概念并描述其工作原理。然后，我们专注于两个主要领域
1. 支持代码生成目前不支持的**新类型**。其中一个呼声很高的类型是 TypeScript 中的字符串联合类型。
一个由几个人组成的团队进入会议室来解决这个任务。他们在此过程中遇到并克服了一些困难，例如如何为代码生成运行单元测试。他们花了一些时间理解代码执行流程，然后才开始处理代码。经过几个小时的协作，他们最终得到了第一个能够识别字符串联合的原型。这次经历对于讨论设计模式以及我们未来可能需要的理想架构非常有帮助。
2. 改进 **iOS 的自动链接**，它缺少一个用例。
具体来说，当库和应用程序在 monorepo 中共存时，自动链接无法很好地工作。Android 已经支持这种情况，但 iOS 缺少支持。
与贡献者一起开发代码生成，帮助我们认识到在其代码库中工作并非易事。例如，添加对一种类型的支持需要在四个不同的地方复制粘贴相同的代码：使用 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 合作的进展，以及继续这种工作模式以支持即将到来的代码拆分和 tree-shaking 的意图。我们再次讨论了 ES 模块支持，并考虑了潜在的未来功能，例如 Yarn PnP 和 Web 上的输出优化。我们讨论了 Metro 的核心如何与 Jest 共享逻辑和数据结构，以及更多重用的机会。
开发人员提出了关于代码拆分和与第三方工具互操作性的富有洞察力的用例。这促使我们讨论 Metro 中潜在的扩展点以及改进当前文档。
本次讨论为我们第二天的关于简化发布工作流程的会议奠定了良好的基础。
Metro 简化发布工作流程
如前所述，发布 React Native 并非易事。
当我们需要发布 React Native、React Native CLI 和 Metro 时，事情变得更加困难。这些工具彼此关联，因为 React Native 和 CLI 都依赖于 Metro。当任何软件包发布新版本时，这会产生一些摩擦。
目前，我们通过直接沟通和同步发布来管理这一点，但仍有改进空间。
在本次会议中，我们重新考虑了 React Native、Metro 和 CLI 之间的依赖关系。我们发现，在 “精简核心” 工作期间，当我们从 React Native 中提取 CLI 时，一些设计决策如何使这两个项目相互依赖，并且某些功能在工作中重复。当时的决定是有道理的，并使 CLI 团队能够比以往更快地迭代。
现在是时候重新审视它们，并借鉴两个团队的经验来找出解决之道。因此，Metro 团队将接管 @react-native-community/cli-plugin-metro 的开发，暂时将其移回 React Native 的核心，然后很可能移至 Metro monorepo。
最大的收获，除了在白板上绘制软件包之间依赖关系的三个小时外，还在于 CLI 和 Metro 团队交流了他们的问题、经验和计划，从而更好地相互理解。
如果我们没有真正见面，我们将无法实现这种程度的合作。
我们仍然对几天时间在一起度过几个小时所带来的如此多的知识共享和思想的交叉传播印象深刻。在本次峰会期间，我们为一些倡议播下了种子，这些倡议将帮助我们改进和重塑 React Native 生态系统。
我们再次感谢 Callstack 主办本次峰会，并感谢所有参与者加入我们的 2022 年核心贡献者峰会。
如果您有兴趣加入 React Native 的开发，请务必加入我们的开放性倡议并阅读我们网站上的 贡献指南。我们希望将来也能与您亲自见面！