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 的开发，请务必加入我们的开放倡议并阅读我们网站上的 贡献指南。我们希望未来也能与您面对面交流！