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 个任务**。到 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 打包器，是 React Native 开发体验的基础和集成部分，我们希望确保它与 JS 生态系统中的最新标准协同工作。
本次会议的重点是讨论如何改进 Metro 的功能集，使其更好地适用于 Web 用例，并与 npm 和打包器生态系统协同工作。讨论的两个主要领域是：
1. 采用 `“exports”`（包入口点）规范
摘自 Node.js 文档
采用 `“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 之间的**依赖关系**。我们发现，在“精简核心”工作期间，当我们从 React Native 中提取 CLI 时，一些设计决策导致这两个项目在某些功能上相互依赖，并且在不同工作中存在重复。当时这些决策是合理的，并使 CLI 团队能够比以往更快地迭代。
是时候重新审视它们，并结合两个团队的经验来找出解决方案了。因此，Metro 团队将接管 `@react-native-community/cli-plugin-metro` 的开发，暂时将其移回 React Native 核心，然后很可能移至 Metro monorepo。
除了在白板上绘制包之间的依赖关系花费了三个小时外，最大的收获是 CLI 和 Metro 团队交流了他们的问题、经验和计划，从而更好地相互理解。
如果我们没有真正见面，我们无法达到这种合作水平。
几天来，我们在一起度过了几个小时，取得了如此多的知识共享和思想交流，这仍然让我们印象深刻。在这次峰会期间，我们播下了有助于改进和重塑 React Native 生态系统的倡议的种子。
我们再次感谢 Callstack 的款待，感谢所有参与者加入我们 2022 年核心贡献者峰会。
如果您有兴趣加入 React Native 的开发，请务必加入我们的开放倡议并阅读我们网站上的贡献指南。我们希望将来也能与您本人见面！