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 モノレポ
- Metro Webおよびエコシステムの連携
- Metro簡略化されたリリースワークフロー
この2日間で、多くの知識共有とコラボレーションが行われたことに感銘を受けました。このブログ記事では、この集まりの結果を少しだけお見せしたいと思います。
React Native CodegenとTypeScriptのサポート
React NativeのCodegenは、React Nativeの新しいアーキテクチャの基本的な部分です。そのサポートと改善は、React Nativeの将来にとって最優先事項の1つです。たとえば、今年の初めには、FlowではなくTypeScriptの仕様から始まるジェネリックコードのサポートを追加しました。
このセッションでは、Codegenのコアコンセプトを説明し、その仕組みを説明することで、新しいコントリビューターをCodegenにオンボーディングする機会を得ました。その後、次の2つの主要な領域に焦点を当てました。
1. Codegenで現在サポートされていない**新しい型**のサポート。最も要望の多かったものの1つは、TypeScriptの文字列ユニオン型でした。
数人のチームが会議室に移動して、このタスクに取り組みました。Codegenの単体テストをどのように実行するかなど、途中でいくつかの困難に遭遇し、克服しました。コードを処理する前に、コードの実行フローを理解するのにかなりの時間を費やしました。数時間の共同作業の後、文字列ユニオンを認識できる最初のプロトタイプが完成しました。この経験は、デザインパターンと、将来的に理想的なアーキテクチャについて議論する上で非常に役立ちました。
2. **iOSの自動リンク**の改善。これはユースケースが欠落していました。
具体的には、ライブラリとアプリがモノレポで共存しているシナリオでは、自動リンクがうまく機能しませんでした。Androidはすでにこのユースケースをサポートしていましたが、iOSには欠けていました。
Codegenのコントリビューターと協力することで、そのコードベースでの作業は簡単ではないことに気づきました。たとえば、1つの型のサポートを追加するには、Flowで記述された仕様を持つモジュール、TypeScriptで記述された仕様を持つモジュール、Flowで記述された仕様を持つコンポーネント、およびTypeScriptで記述された仕様を持つコンポーネントという4つの異なる場所で同じコードをコピーアンドペーストする必要がありました。
この認識により、より保守しやすいコードベースに向けて、コミュニティに助けを求める包括的なタスクを作成するに至りました。
参加は素晴らしいものでした。最初の**40タスクを5日間で**迅速に割り当てることができました。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のNew Architecture Working Groupにご連絡ください。
React Native Monorepo
現在、React Nativeの新しいバージョンをリリースするのは簡単なことではありません。React NativeはNPMで最もダウンロードされているパッケージの1つであり、リリースプロセスがスムーズに進むようにしたいと考えています。
そのため、react-nativeリポジトリをリファクタリングし、Monorepo RFC（#480）を実装したいと考えています。
このセッションでは、まずすべてのコントリビューターから意見を集め、ブレインストーミングを行いました。これは、ダウンストリームの依存関係に対する破壊的な変更を減らすために、リポジトリを進化させることが重要であるためです。
その後、2つの側面から取り組みを開始しました。まず、モノレポをサポートするために継続的インテグレーションのインフラストラクチャを拡張する必要があり、テストインフラストラクチャにVerdaccioを追加しました。次に、いくつかのパッケージの名前を変更し、スコープを追加し始め、結果として6つの異なる貢献がありました。
この取り組みの状況は、この包括的なIssueで追跡できます。近い将来、この取り組みについてさらに共有できることを願っています。
Metro Webとエコシステムの連携
Metroは、React Nativeの開発体験の基盤となる不可欠な一部であるJavaScriptバンドラーであり、JSエコシステムの最新標準で動作するようにしたいと考えています。
このセッションの焦点は、Webユースケースやnpmおよびバンドラーのエコシステムでより適切に動作するようにMetroの機能セットを改善することについて議論することでした。主な議論の領域は2つです。
1. "exports" (パッケージエントリポイント) 仕様の採用
"exports"仕様の採用には大きな可能性があります。このセッションでは、プラットフォーム固有のコードを"exports"でどのように処理するかについて議論しました。多くの要因を考慮し、Metroリゾルバーに"strict"モードと"non-strict"モードを追加することにより、"exports"の比較的非破壊的なロールアウト計画を策定しました。builder-bobを活用することで、ライブラリの作成者が摩擦なく厳密モードを採用できるようになる方法について議論しました。
この議論の結果、
- パッケージのエクスポートがReact Nativeでどのように機能するかに関するMetroのRFCが作成されました。
- Node.jsのRFCで、「react-native」をコミュニティ条件として含めることが提案されました。
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から抽出した際、これらの2つのプロジェクトが相互依存になり、一部の機能が重複していることが明らかになりました。当時の決定は理にかなっており、CLIチームがこれまで以上に迅速にイテレーションを行うことができました。
両方のチームの経験を生かして、解決策を見つけるために再検討する時期が来ました。その結果、Metroチームは@react-native-community/cli-plugin-metroの開発を引き継ぎ、一時的にReact Nativeのコアに戻し、その後、おそらくMetroモノレポに移動する予定です。
ホワイトボード上でパッケージ間の依存関係を3時間かけて描き出したこと以外に、最大の収穫は、CLIチームとMetroチームがそれぞれの課題、経験、計画を交換し、お互いの理解を深めることができたことでした。
実際に会わなければ、このレベルの協力は達成できなかったでしょう。
数日間一緒に過ごすだけで、これほど多くの知識共有とアイデアの相互交流が実現したことに、今でも感銘を受けています。このサミットでは、React Nativeエコシステムを改善し、再構築するのに役立つイニシアチブの種を植えました。
ホストしてくれたCallstackと、Core Contributor Summit 2022に参加してくれたすべての参加者に改めて感謝申し上げます。
React Nativeの開発に参加することに興味がある場合は、私たちのオープンなイニシアチブに参加し、ウェブサイトに掲載されている貢献ガイドを必ずお読みください。今後、皆様と直接お会いできることを願っています！