React Native 核心贡献者峰会 2022
在经历了多年的疫情和线上活动后，我们真切地觉得是时候将 React Native 的核心贡献者们聚集在一起了！
因此，在九月初，我们召集了 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 中的字符串联合类型（string union types）。
几个人组成的小组进入会议室来处理这项任务。他们在此过程中遇到并克服了一些困难，例如如何运行 Codegen 的单元测试。他们花了不少时间理解代码执行流程，然后才开始处理代码。经过数小时的协作工作，他们最终拿出了第一个能够识别字符串联合的原型。这次经历对于讨论设计模式和我们未来可能需要的理想架构非常有帮助。
2. 改进 iOS 上的自动链接（auto-linking），它缺少一个用例。
具体来说，在库和应用程序共存于 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 项不同的贡献。
您可以在此伞形问题下跟踪这项工作的状态，我们希望在不久的将来分享更多关于这项工作的进展。
Metro Web 及生态系统对齐
Metro，我们的 JavaScript Bundler，是 React Native 开发体验的基础和集成部分，我们希望确保它与 JavaScript 生态系统中的最新标准保持一致。
本次会议的重点是讨论如何改进 Metro 的功能集，使其更好地支持 Web 用例，并与 npm 和 Bundler 生态系统协同工作。讨论的两个主要领域是：
1. 采用 "exports" (包入口点) 规范
摘自 Node.js 文档
采用 "exports" 规范具有巨大的潜力。在本次会议中，我们讨论了如何使用 "exports" 处理平台特定代码。综合考虑多种因素，我们提出了一项相对非破坏性的 "exports" 推广计划，即向 Metro 解析器添加 "strict" 和 "non-strict" 模式。我们讨论了如何利用 builder-bob 帮助库创建者无障碍地采用严格模式。
这次讨论产生了：
2. Web 和 Bundler 生态系统
Metro 团队分享了他们与 Expo 合作的进展，并表示有意为即将到来的包拆分（bundle splitting）和摇树优化（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 的开发，请务必加入我们的开放倡议并阅读我们网站上的贡献指南。我们希望未来也能与您面对面交流！