React Canaries: Meta外での段階的機能ロールアウトの実現

2023年5月3日 by Dan Abramov、Sophie Alpert、Rick Hanlon、Sebastian Markbåge、Andrew Clark

Reactコミュニティに対して、個々の新機能を安定版でリリースされる前に、設計がほぼ最終段階に近づいた時点で採用できるオプションを提供したいと考えています。これは、Metaが長年内部でReactの最新版を使用してきた方法と同様です。新しく公式にサポートされたCanaryリリースチャンネルを導入します。これにより、フレームワークなどの厳選されたセットアップが、個々のReact機能の採用をReactのリリーススケジュールから切り離すことができます。

tl;dr

• Reactの公式にサポートされたCanaryリリースチャンネルを導入します
• 公式にサポートされているため、リグレッションが発生した場合は、安定版リリースのバグと同様の緊急度で対処します
• Canariesを使用すると、semver安定版リリースに含まれる前に、個々の新しいReact機能を使い始めることができます
• Experimentalチャンネルとは異なり、React Canariesには採用準備ができていると合理的に判断される機能のみが含まれます
• フレームワークには、固定されたCanary Reactリリースをバンドルすることを検討することをお勧めします
• Canaryリリースに含まれる破壊的変更と新機能については、ブログで発表します
• いつものように、ReactはすべてのStableリリースでsemverに従い続けます

React機能の通常の開発方法

通常、すべてのReact機能は同じ段階を経ています：

1. 初期バージョンを開発し、experimental_またはunstable_のプレフィックスを付けます。機能はexperimentalリリースチャンネルでのみ利用可能です。この時点で、機能は大幅に変更されることが予想されます。

2. Metaでこの機能をテストし、フィードバックを提供してくれるチームを見つけます。これにより一連の変更が行われます。機能がより安定してくると、Metaのより多くのチームと協力して試用します。

3. 最終的に、設計に自信を持てるようになります。API名からプレフィックスを削除し、ほとんどのMeta製品が使用するメインブランチでデフォルトで機能を利用可能にします。この時点で、Metaのどのチームでもこの機能を使用できます。

4. 方向性に自信を深めると、新機能のRFCも投稿します。この時点で、設計が幅広いケースで機能することがわかりますが、最後の微調整を行う可能性があります。

5. オープンソースリリースを準備する段階に近づくと、機能のドキュメントを作成し、最終的に安定版Reactリリースで機能をリリースします。

このプレイブックは、これまでにリリースしたほとんどの機能でうまく機能しています。しかし、機能が一般的に使用準備ができた時点（ステップ3）とオープンソースでリリースされる時点（ステップ5）の間には大きなギャップがある場合があります。

Reactコミュニティに対して、Metaと同じアプローチに従い、Reactの次のリリースサイクルを待つことなく、個々の新機能をより早期に（利用可能になった時点で）採用できるオプションを提供したいと考えています。いつものように、すべてのReact機能は最終的にStableリリースに含まれます。

より多くのマイナーリリースを行うだけではだめなのか？

一般的に、新機能の導入にはマイナーリリースを使用しています。しかし、これが常に可能とは限りません。時には、新機能がまだ完全に完成しておらず、まだ積極的に反復している他の新機能と相互接続されている場合があります。実装が関連しているため、それらを個別にリリースすることはできません。同じパッケージ（例：reactとreact-dom）に影響するため、個別にバージョン管理することもできません。そして、semverが要求する大量のメジャーバージョンリリースなしに、準備ができていない部分を反復する能力を維持する必要があります。

Metaでは、メインブランチからReactをビルドし、毎週特定の固定コミットに手動で更新することで、この問題を解決しています。これは、React Nativeリリースが過去数年間従ってきたアプローチでもあります。React Nativeのすべての安定版リリースは、Reactリポジトリのメインブランチからの特定のコミットに固定されています。これにより、React Nativeは重要なバグ修正を含め、グローバルなReactリリーススケジュールに結合されることなく、フレームワークレベルで新しいReact機能を段階的に採用できます。

このワークフローを他のフレームワークや厳選されたセットアップでも利用できるようにしたいと考えています。例えば、React上のフレームワークが、破壊的変更が安定版Reactリリースに含まれる前に、React関連の破壊的変更を含めることができます。一部の破壊的変更はフレームワーク統合にのみ影響するため、これは特に有用です。これにより、フレームワークはsemverを破ることなく、独自のマイナーバージョンでそのような変更をリリースできます。

Canariesチャンネルでのローリングリリースにより、より密接なフィードバックループを持ち、新機能がコミュニティで包括的なテストを受けることを保証できます。このワークフローは、JavaScript標準委員会であるTC39が番号付きステージで変更を処理する方法により近いものです。新しいReact機能は、React安定版リリースに含まれる前に、React上に構築されたフレームワークで利用可能になる場合があります。これは、新しいJavaScript機能が仕様の一部として正式に批准される前にブラウザに搭載されるのと同様です。

なぜexperimentalリリースを使用しないのか？

技術的にはExperimentalリリースを使用することもできますが、experimental APIは安定化の過程で大幅な破壊的変更を受ける可能性がある（または完全に削除される可能性もある）ため、本番環境での使用は推奨しません。

Canariesにも間違いが含まれる可能性がありますが（他のリリースと同様）、今後はCanariesの重要な破壊的変更についてはブログで発表する予定です。CanariesはMetaが内部で実行しているコードに最も近いため、一般的に比較的安定していることが期待できます。ただし、バージョンを固定し、固定コミット間で更新する際にはGitHubコミットログを手動でスキャンする必要があります。

フレームワークなどの厳選されたセットアップ外でReactを使用するほとんどの人は、Stableリリースを使い続けることを期待しています。ただし、フレームワークを構築している場合は、特定のコミットに固定されたCanaryバージョンのReactをバンドルし、独自のペースで更新することを検討する価値があるかもしれません。

その利点は、React Nativeが過去数年間行ってきたように、完成した個々のReact機能とバグ修正をユーザーにより早く、独自のリリーススケジュールで提供できることです。欠点は、どのReactコミットが取り込まれているかをレビューし、どのReact変更がリリースに含まれているかをユーザーに伝える追加の責任を負うことです。

フレームワーク作成者でこのアプローチを試したい場合は、ぜひご連絡ください。

破壊的変更と新機能の早期発表

Canaryリリースは、任意の時点で次の安定版Reactリリースに含まれる内容の最良の推測を表しています。

従来、破壊的変更はリリースサイクルの終わり（メジャーリリース時）にのみ発表していました。Canaryリリースが公式にサポートされたReactの消費方法となったため、Canariesにランディングするタイミングで破壊的変更と重要な新機能を発表する方向にシフトする予定です。

例えば、Canaryで出力される破壊的変更をマージした場合、必要に応じてコードモッドと移行手順を含めて、Reactブログでそれについての投稿を書きます。その後、その変更を含むように固定されたReact canaryを更新するメジャーリリースを行うフレームワーク作成者は、リリースノートから私たちのブログ投稿にリンクできます。最後に、Reactの安定版メジャーバージョンが準備できたら、すでに公開されているブログ投稿にリンクし、これによりチームがより速く進歩できることを期待しています。

CanariesにランディングしたAPIについては、それらがCanaries外ではまだ利用できない場合でも、ドキュメント化する予定です。Canariesでのみ利用可能なAPIは、対応するページで特別な注記でマークされます。これにはuseなどのAPIや、RFCを送信予定の他のAPI（cacheやcreateServerContextなど）が含まれます。

Canariesは固定する必要があります

アプリやフレームワークでCanaryワークフローを採用することを決定した場合は、使用しているCanaryの正確なバージョンを常に固定してください。Canariesはプレリリースであるため、まだ破壊的変更が含まれる可能性があります。

例：React Server Components

3月に発表したように、React Server Componentsの規約は確定しており、ユーザー向けAPIコントラクトに関連する重要な破壊的変更は予想していません。しかし、まだいくつかの相互に絡み合ったフレームワーク専用機能（アセット読み込みなど）に取り組んでおり、そこでより多くの破壊的変更を予想しているため、React Server ComponentsのサポートをReactの安定版でリリースすることはまだできません。

これは、React Server Componentsがフレームワークによる採用準備ができていることを意味します。しかし、次のReactメジャーリリースまでは、フレームワークがそれらを採用する唯一の方法は、固定されたCanaryバージョンのReactを出荷することです。（Reactの2つのコピーをバンドルすることを避けるため、これを行いたいフレームワークは、フレームワークと一緒に出荷する固定Canaryにreactとreact-domの解決を強制し、それをユーザーに説明する必要があります。例として、これはNext.js App Routerが行っていることです。）

StableとCanaryの両バージョンに対するライブラリのテスト

ライブラリ作成者がすべてのCanaryリリースをテストすることは困難すぎるため、期待していません。しかし、3年前に異なるReactプレリリースチャンネルを最初に導入した時と同様に、最新のStableと最新のCanaryバージョンの両方に対してテストを実行することをライブラリに推奨します。発表されていない動作の変更を見つけた場合は、診断を支援できるよう、Reactリポジトリにバグを報告してください。

この慣行が広く採用されるようになると、偶発的なリグレッションがランディング時に発見されるため、ライブラリをReactの新しいメジャーバージョンにアップグレードするために必要な労力が削減されることを期待しています。

注記

厳密に言えば、Canaryは新しいリリースチャンネルではありません。以前はNextと呼ばれていました。しかし、Next.jsとの混同を避けるために名前を変更することにしました。Canariesが公式にサポートされたReactの使用方法であるなど、新しい期待を伝えるために新しいリリースチャンネルとして発表しています。

安定版リリースは以前と同様に機能します

安定版Reactリリースには変更を導入していません。