React Native 核心貢獻者峰會 2022
經過多年的疫情和僅限線上的活動，我們真的覺得是時候讓 React Native 的核心貢獻者齊聚一堂了！
這就是為什麼在 9 月初，我們聚集了一些活躍的 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 Bundler，是 React Native 開發體驗的基礎和整合部分，我們希望確保它與 JS 生態系統中的最新標準相容。
這次會議的重點是討論改進 Metro 的功能集，使其更適用於 Web 使用案例以及 npm 和 bundler 生態系統。兩個主要的討論領域
1. 採用 "exports" (套件進入點) 規格
摘自 Node.js 文件
採用 "exports" 規格具有很大的潛力。在這次會議中，我們討論了如何使用 "exports" 處理 平台特定程式碼。考慮到許多因素，我們為 "exports" 制定了一個相當不具破壞性的推出計畫，方法是在 Metro 解析器中新增 "strict" 和 "non-strict" 模式。我們討論了如何利用 builder-bob 來幫助程式庫建立者無摩擦地採用嚴格模式。
這次討論促成了
2. Web 和 bundler 生態系統
Metro 團隊分享了他們與 Expo 合作的進展，以及繼續將此工作模式用於即將推出的 bundle splitting 和 tree-shaking 支援的意圖。我們再次談到了 ES 模組支援，並考慮了潛在的未來功能，例如 Yarn PnP 和 Web 上的輸出最佳化。我們討論了 Metro 的核心如何與 Jest 共享邏輯和資料結構，以及更多重用的機會。
開發人員提出了關於 bundle splitting 和與第三方工具互通性的深刻使用案例。這引導我們討論 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 的開發，請務必加入我們的開放倡議，並閱讀我們網站上的 貢獻指南。我們希望在未來也能與您親自見面！