React Native 核心贡献者峰会 2022
本页面由 PageTurner AI 翻译（测试版）。未经项目官方认可。 发现错误？ 报告问题 →
经历多年疫情和纯线上活动后，我们深感是时候让 React Native 的核心贡献者们齐聚一堂了！
因此九月初，我们召集了 React Native 活跃的核心贡献者、库维护者以及 Meta 的 React Native 和 Metro 团队，共同举办了2022 核心贡献者峰会。Callstack 在其波兰弗罗茨瓦夫总部承办了本次峰会，同期还举办了 React Native EU 大会。
我们与 React Native 核心团队共同策划了一系列工作坊，参与者可选择加入以下主题：
-
React Native Codegen 与 TypeScript 支持
-
React Native 新架构库迁移
-
React Native 单体仓库
-
Metro Web 与生态对齐
-
Metro 简化发布流程
为期两天的深度知识共享与协作令人印象深刻。本文中，我们将带您先睹为快本次峰会的成果。
React Native Codegen 与 TypeScript 支持
React Native 的 Codegen 是新架构的核心组成部分。其支持与改进是我们未来的首要任务之一。例如今年早些时候，我们新增了基于 TypeScript 规范（而非 Flow）生成通用代码的功能。
本次工作坊中，我们借此机会向新贡献者介绍了 Codegen 的核心概念与运作机制，随后聚焦两大重点领域：
1. 支持 Codegen 当前未覆盖的新类型。其中呼声最高的是 TypeScript 字符串联合类型。
小组成员在会议室集中攻克此任务。过程中克服了诸多挑战，例如如何运行 Codegen 单元测试。团队投入大量时间理解代码执行流程后才着手编码。经过数小时协作，最终成功实现可识别字符串联合类型的初版原型。此经验对探讨未来理想架构与设计模式极具价值。
2. 改进 iOS 自动链接功能，填补特定场景缺失。
具体而言，当库与应用共存于单体仓库时，自动链接功能表现欠佳。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 并非易事。作为 npm 下载量最高的包之一，我们希望确保发布流程顺畅无阻。
为此我们计划重构 react-native 仓库并实施Monorepo RFC（#480）。
本环节首先通过头脑风暴收集每位贡献者的意见，这对优化仓库演进路径至关重要，可最大限度减少对下游依赖项的破坏性变更。
随后我们从两个方向着手：一方面扩展持续集成（CI）基础设施以支持 monorepo，在测试环境中引入 Verdaccio；另一方面启动多个包的重命名和作用域化工作，最终产生了 6 项独立贡献。
您可通过此统筹问题追踪进展，我们将在近期分享更多成果。
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 共享逻辑和数据结构，以及进一步复用这些资源的可能性。
开发者们提出了关于代码分割的深刻用例，以及如何与第三方工具实现互操作性。这引导我们探讨了在 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 的 monorepo 中。
除了在白板上花费三小时梳理软件包依赖关系外，最重要的收获是 CLI 和 Metro 团队通过交流彼此的痛点、经验和规划，加深了相互理解。
如果没有这次线下聚会，我们不可能达成如此深度的合作。
我们至今仍惊叹于短短几天的相聚竟能促成如此丰富的知识共享和创意碰撞。这次峰会上播下的种子，将帮助我们改善并重塑 React Native 的生态系统。
再次感谢 Callstack 承办本次峰会，也感谢所有参与 2022 核心贡献者峰会的伙伴们。
如果您有兴趣参与 React Native 的开发，欢迎加入我们的开源计划并阅读官网的贡献指南。期待未来能与您线下相见！