段階的な機能採用: 開発者は、現在のメジャーバージョンで利用可能になった新しい機能や変更を、一つずつ選択して統合する柔軟性を持つことができます。これは、すべての変更を単一の新しいメジャーリリースにまとめる従来の方法からの脱却です。
シームレスなバージョンアップグレード: 新しい機能を事前に選択的に組み込むことで、開発者は既存のアプリケーションコードを変更することなく、新しいメジャーバージョンにスムーズに移行できます。

不安定なAPIと将来のフラグ

unstable_someFeature のような将来のフラグを使用して、現在のリリースに新しい機能を導入します。これらのフラグは、vite.config.ts ファイルの Remix Vite Plugin future オプションで指定できます。

vite.config.ts

import { vitePlugin as remix } from "@remix-run/dev";
import { defineConfig } from "vite";
 
export default defineConfig({
  plugins: [
    remix({
      future: {
        unstable_someFeature: true,
      },
    }),
  ],
});

まだ Vite を使用していない場合は、remix.config.js future オプションを介して将来のフラグを提供できます。

不安定な機能が安定した状態に達すると、特別なプレフィックスを削除し、次のマイナーリリースにその機能を含めます。この時点で、API の構造は後続のマイナーリリース全体で一貫性が保たれます。
このアプローチにより、早期採用者と協力して API を改良し、すべてのユーザーに影響を与えることなく、不安定な段階で必要な変更を組み込むことができます。安定版リリースは、中断することなくこれらの改善の恩恵を受けることができます。
unstable_* フラグでラベル付けされた機能を使用している場合は、各マイナーリリースのリリースノートを確認することが重要です。これは、これらの機能の動作や構造が進化する可能性があるためです。この段階でのフィードバックは、最終リリース前に機能を強化する上で非常に貴重です。

将来のフラグによる破壊的変更の管理

破壊的変更を導入する場合、現在のメジャーバージョンのコンテキスト内で行い、将来のフラグの背後に隠します。たとえば、v2 にいる場合、破壊的変更は v3_somethingDifferent という名前の将来のフラグの下に配置される可能性があります。

vite.config.ts

import { vitePlugin as remix } from "@remix-run/dev";
import { defineConfig } from "vite";
 
export default defineConfig({
  plugins: [
    remix({
      future: {
        v3_someFeature: true,
      },
    }),
  ],
});

既存の v2 の動作と新しい v3_somethingDifferent の動作の両方が同時に共存します。
アプリケーションは、次のメジャーリリースですべての変更に一度に対応する必要はなく、一度に1ステップずつ変更を段階的に採用できます。
すべての v3_* 将来のフラグが有効になっている場合、v3 への移行は、理想的にはコードベースへの変更を必要としないはずです。
破壊的変更をもたらす一部の将来のフラグは、最初は unstable_* フラグとして開始されます。これらはマイナーリリース中に変更される可能性があります。v3_* 将来のフラグになると、対応する API は設定され、それ以上変更されることはありません。

まとめ

私たちの開発戦略は、メジャーリリースにおける段階的な機能採用とシームレスなバージョンアップグレードに焦点を当てています。これにより、開発者は新しい機能を選択的に統合できるようになり、バージョン移行中に大規模なコード調整を行う必要がなくなります。unstable_* フラグを介して機能を導入することで、早期採用者と協力して API を改良し、安定版リリースが機能強化の恩恵を受けるようにします。v3_* フラグを使用した破壊的変更の慎重な管理を通じて、変更を段階的に採用する柔軟性を提供し、メジャーバージョン間のスムーズな移行を促進します。これにより、Remix フレームワークの開発の複雑さは増しますが、この開発者中心のアプローチは、Remix を使用したアプリケーション開発を大幅に簡素化し、最終的にはソフトウェアの品質向上と（うまくいけば！）開発者の満足度向上につながります。

不安定なAPIと将来のフラグ
将来のフラグによる破壊的変更の管理
まとめ