React Native核心贡献者峰会2022
在经历了多年的疫情和纯线上活动后，我们确实认为是时候将 React Native 的核心贡献者们聚集在一起了！
因此，在 9 月初，我们邀请了一些活跃的 React Native 核心贡献者、库维护者以及 Meta 的 React Native 和 Metro 团队，参加了 **2022 年核心贡献者峰会**。 Callstack 在其位于波兰弗罗茨瓦夫的总部举办了此次峰会，作为同期举行的 React Native EU 会议的一部分。
我们与 React Native 核心团队一起设计了一系列 **研讨会**，供与会者参与。主题包括：
- React Native 代码生成和 TypeScript 支持
- React Native 新架构库迁移
- React Native 单体仓库
- Metro Web 和生态系统对齐
- Metro 简化发布工作流
我们对这两天知识共享和合作的程度印象深刻。在这篇博文中，我们想让您一窥此次聚会的成果。
React Native 代码生成和 TypeScript 支持
React Native 的代码生成 是 React Native 新架构的基础部分。支持和改进它是我们 React Native 未来首要任务之一。例如，今年早些时候，我们添加了从 TypeScript 规范而不是 Flow 开始支持泛型代码的功能。
在本环节中，我们借此机会让新的贡献者了解代码生成，通过解释其核心概念并描述其工作原理。然后我们重点关注两个主要方面：
1. 支持 **新类型**，这些类型目前不受代码生成支持。其中一个强烈要求的是 TypeScript 中的字符串联合类型。
几个人组成的团队进入一个会议室来处理这项任务。他们在过程中遇到并克服了一些困难，例如如何运行代码生成的单元测试。他们在开始处理代码之前花了一些时间来理解代码执行流程。经过几个小时的协作工作，他们最终得到了能够识别字符串联合类型的第一个原型。这段经历对于讨论设计模式以及我们将来可能需要的理想架构非常有用。
2. 改进 **iOS 的自动链接**，它缺少一个用例。
具体来说，在库和应用一起存在于单体仓库中的情况下，自动链接无法正常工作。Android 已经支持了这个用例，但 iOS 缺少它。
与代码生成的贡献者合作帮助我们意识到，在其代码库中工作并非易事。例如，添加对一种类型的支持需要在四个不同的地方复制粘贴相同的代码：使用 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 单体仓库
今天发布 React Native 的新版本并非易事。React Native 是 NPM 上下载次数最多的软件包之一，我们希望确保我们的发布流程顺利进行。
这就是为什么我们要重构 react-native 存储库并实施 **单体仓库 RFC** (#480)。
在本环节中，我们最初进行了头脑风暴并收集了每个贡献者的意见，因为我们必须改进我们的存储库以减少对下游依赖项的重大更改至关重要。
然后我们开始在两个方面开展工作。首先，我们必须扩展我们的持续集成基础设施以支持我们的单体仓库，在我们的测试基础设施中添加 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 之间的**依赖关系**。我们发现，在“精简核心”工作期间，当我们将 CLI 从 React Native 中提取出来时，一些设计决策使这两个项目相互依赖，并且某些功能在工作中重复。当时的决策是有意义的，并且允许 CLI 团队比以往任何时候都更快地迭代。
是时候重新审视它们并利用两个团队的经验来找到解决方法了。因此，Metro 团队将接管@react-native-community/cli-plugin-metro的开发，暂时将其移回 React Native 的核心，然后很可能移到 Metro 的单仓中。
除了在白板上绘制了三个小时的包之间依赖关系之外，最大的收获是 CLI 和 Metro 团队能够交换他们的问题、经验和计划，从而更好地了解彼此。
如果没有真正见面，我们就无法实现这种程度的合作。
我们仍然对几天内花几个小时在一起就能产生如此多的知识共享和思想交叉感到印象深刻。在这次峰会上，我们为了一些举措播下了种子，这些举措将帮助我们改进和重塑 React Native 生态系统。
我们要再次感谢Callstack的热情接待，并感谢所有参加 2022 年核心贡献者峰会的参与者。
如果您有兴趣加入 React Native 的开发，请务必加入我们的开放计划并阅读我们网站上的贡献指南。我们希望将来也能与您当面见面！