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 中的字符串联合类型。
几位成员组成了一个小组，在会议室集中攻克此任务。期间遇到并克服了一些难题，比如如何为 Codegen 运行单元测试。他们花费不少时间搞懂代码执行流程，才开始动手写代码。经过数小时的协作，最终实现了第一个能够识别字符串联合类型的原型。此次经验对讨论设计模式及未来理想架构极有帮助。
2. 改进**iOS 自动链接功能**，此前缺少一个用例支持。
具体来说，自动链接在库和应用共存于多包仓库（monorepo）中时表现不佳。Android 已支持此用例，但 iOS 缺失。
与 Codegen 贡献者的合作让我们意识到其代码库并不简单。例如，支持某一类型需要在四个不同位置复制粘贴相同代码：Flow 编写规范的模块、TypeScript 编写规范的模块、Flow 编写规范的组件、TypeScript 编写规范的组件。
这一发现促使我们建立了统筹任务，向社区寻求帮助，改善代码库状态，使其更具可维护性。
参与度极高：我们在 5 天内迅速分配了首批 40 个任务。到了十月底，社区完成了 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 仓库并实施 多包仓库 RFC（#480）。
此次会议我们先进行头脑风暴，并收集了每位贡献者的观点，因为降低下游依赖的破坏性变更有赖于仓库的演进。
接着，我们并行推动两项工作。首先，为支持多包仓库，我们扩展了持续集成基础设施，将 Verdaccio 加入测试体系。然后开始对多个包进行重命名及添加 scope，共产生 6 条贡献。
你可通过此统筹 Issue跟踪进展，我们也将尽快分享更多信息。
Metro Web 及生态系统对齐
Metro 是我们的 JavaScript 打包器，是 React Native 开发体验的重要组成部分。我们希望 Metro 与 JS 生态中的最新标准保持兼容。
本环节重点讨论提升 Metro 特性，以更好支持 Web 用例及 npm 和打包器生态。两大讨论点：
1. 采纳 "exports" 规范（包入口点）
根据 Node.js 文档：
"exports" 提供了一个现代替代方案给 "main"，允许定义多个入口点，支持环境间条件入口解析，且阻止除了 "exports" 中定义的其他入口点。这种封装让模块作者能清楚定义包的公共接口。
采纳 "exports" 规范潜力巨大。在会议中，我们讨论了如何用 "exports" 处理平台特定代码。综合多种因素后，提出了一个较为不破坏兼容性的分阶段计划，通过为 Metro 解析器增加 "strict" 和 "non-strict" 模式。我们也讨论了如何利用 builder-bob 帮助库开发者无障碍采用严格模式。
这次讨论产出了：
2. Web 与打包器生态
Metro 团队分享了与 Expo 合作进展及其继续采用该工作模式支持未来打包拆分和摇树优化的计划。我们重新讨论了 ES 模块支持以及未来可能支持 Yarn PnP 和 Web 端输出优化的功能。探讨了 Metro 核心与 Jest 共用逻辑和数据结构的机会及可复用性。
开发者提出了对打包拆分和与第三方工具互操作的实际用例，促使我们探讨 Metro 潜在的扩展点及文档改进方案。
这些讨论为次日简化发布流程会议打下了坚实基础。
Metro 简化发布流程
正如前述，发布 React Native 并非易事。
情况更复杂的是，我们需同时发布 React Native、React Native CLI 和 Metro。这些工具相互依赖，React Native 和 CLI 都依赖 Metro，任一包发布新版会带来协调困难。
目前我们通过直接沟通和同步发布来管理，但仍有提升空间。
本环节重新考量了 React Native、Metro 和 CLI 三者的依赖关系。回顾了 “Lean Core” 工作中，将 CLI 从 React Native 中抽离时做出的一些设计决策，这些决策让两个项目产生了代码依赖且部分功能重复。当年决定有其合理性，让 CLI 团队迭代更快。
现在是重新审视这些决策、汇聚两团队经验探索前行路的时候了。最终 Metro 团队将接管 @react-native-community/cli-plugin-metro 的开发，项目暂时回归 React Native 核心，随后很可能迁移到 Metro 多包仓库中。
最大的收获，除去三小时在白板上梳理包间依赖外，是 CLI 和 Metro 团队相互交流彼此的问题、经验和规划，增进了相互理解。
没有面对面交流，我们达不到如此协作水平。
我们仍对几天数小时的共聚带来的丰富知识分享和观点交融感到震撼。此次峰会为改进和重塑 React Native 生态系统播下了种子。
我们再次感谢 Callstack 的主办及所有参与者加入核心贡献者峰会 2022。
如果你有兴趣参与 React Native 开发，务必加入我们的开放计划，并阅读我们网站上的贡献指南。期待未来与你的亲自相会！