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の将来にとって最優先事項の一つです。例えば、今年の初めには、FlowではなくTypeScriptの仕様からコードを生成するサポートを追加しました。
このセッションでは、Codegenのコアコンセプトを説明し、その仕組みを解説することで、新しいコントリビューターをCodegenに迎え入れる機会を得ました。その後、私たちは2つの主要な領域に焦点を当てました。
1. 現在Codegenでサポートされていない新しい型のサポート。要望が多かったものの一つに、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の新アーキテクチャワーキンググループまでご連絡ください。
React Native モノレポ
React Nativeの新バージョンをリリースすることは、現在、簡単ではありません。React NativeはNPMで最もダウンロードされているパッケージの1つであり、私たちはリリースプロセスがスムーズであることを確認したいと考えています。
そのため、私たちは`react-native`リポジトリをリファクタリングし、モノレポRFC (#480) を実装したいと考えています。
このセッションでは、まずすべてのコントリビューターから意見を収集し、ブレインストーミングを行いました。これは、下流の依存関係に対する破壊的変更を減らすためにリポジトリを進化させることが非常に重要だからです。
その後、私たちは2つの側面から作業を開始しました。まず、モノレポをサポートするために継続的インテグレーションインフラを拡張する必要があり、テストインフラにVerdaccioを追加しました。次に、いくつかのパッケージの名前変更とスコープの追加を開始し、結果として6つの個別のコントリビューションが生まれました。
この取り組みの状況は、このアンブレライシューで追跡できます。近い将来、この取り組みについてさらに多くのことを共有できることを願っています。
Metro Web とエコシステムのアラインメント
私たちのJavaScriptバンドラーであるMetroは、React Nativeの開発体験の基礎であり統合された部分であり、JSエコシステムの最新の標準で動作することを確認したいと考えています。
このセッションの焦点は、Metroの機能セットを改善し、Webのユースケースやnpmおよびバンドラーエコシステムとより良く連携させることについて議論することでした。主な議論の2つの領域は以下の通りです。
1. `"exports"` (パッケージエントリーポイント) 仕様の採用
`"exports"`は`"main"`の現代的な代替手段を提供し、複数のエントリーポイントの定義、環境間の条件付きエントリー解決のサポート、そして`"exports"`で定義されたもの以外のエントリーポイントを防ぐことを可能にします。このカプセル化により、モジュールの作成者はパッケージの公開インターフェースを明確に定義できます。
`"exports"` 仕様の採用には多くの可能性があります。このセッションでは、`"exports"`でプラットフォーム固有のコードをどのように扱うかについて議論しました。多くの要因を考慮し、Metroのリゾルバに `"strict"` と `"non-strict"` モードを追加することで、`"exports"` のためのかなり非破壊的な展開計画を立てました。私たちは、builder-bob を活用することで、ライブラリ作成者が摩擦なくstrictモードを採用できる方法について議論しました。
この議論の結果、以下のものが生まれました。
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から抽出した「Lean Core」の取り組みの際のいくつかの設計上の決定が、これら2つのプロジェクトを相互依存させ、いくつかの機能が重複してしまっていることを明らかにしました。当時の決定は理にかなっており、CLIチームはこれまで以上に速くイテレーションを進めることができました。
そろそろそれらを見直し、両チームの経験を生かして解決策を見出す時が来ました。結果として、Metroチームは`@react-native-community/cli-plugin-metro`の開発を引き継ぎ、一時的にReact Nativeのコアに戻し、その後、おそらくMetroのモノレポに移動することになるでしょう。
ホワイトボードにパッケージ間の依存関係を3時間描き続けたこと以外で最大の収穫は、CLIチームとMetroチームがそれぞれの問題、経験、計画を交換し、互いをより良く理解できたことでした。
実際に会うことがなければ、このレベルの協力関係を築くことはできなかったでしょう。
数日間一緒に数時間を過ごすことが、これほど多くの知識共有とアイデアの相互作用をもたらしたことに、私たちは今も感銘を受けています。このサミットの間に、私たちはReact Nativeエコシステムを改善し、再形成するのに役立つイニシアチブの種を蒔きました。
私たちをホストしてくれたCallstack社、そしてコアコントリビューターサミット2022に参加してくれたすべての参加者に、改めて感謝の意を表します。
React Nativeの開発に参加することに興味がある方は、ぜひ私たちのオープンなイニシアチブに参加し、ウェブサイトにあるコントリビューションガイドを読んでください。将来、皆さんとも直接お会いできることを楽しみにしています！