React CRA & Jest から Vite & Vitest への移行で得られた教訓

この記事は、2024 年 12 月 16 日に公開された EDOCODE Advent Calendar 2024 用です。

前回の記事は、EDOCODE プロダクトマネージャー 山田 泰司氏が執筆しました: Notion Webhook とノーコードツール「Make」を使った自動メールシステム (記事は日本語です)。

親会社のWano Advent Calendarもぜひチェックしてください！

はじめに

当社のアプリ Gojiberry は、販売者が顧客から貴重なフィードバックを収集するのに役立つ Shopify アンケート アプリです。

私たちは、アプリにバグがなく、既存の機能を壊すことなく自信を持って新機能をリリースできることを保証するために、最初からテスト駆動開発 (TDD) で Gojiberry を構築してきました。この基盤により、Create React App (CRA) から Vite への移行などの大規模な変更を最小限の中断で行うことができました。

CRA が非推奨になり、その依存関係が時代遅れになったとき、私たちは成長するアプリをより適切にサポートできる最新のビルド ツールにアップグレードする時期が来たと判断しました。コードベースのサイズが大きいため、多少の複雑さが加わりましたが、Vite への切り替えには努力の価値があることがわかりました。

私たちの目標は、2 つの React プロジェクトを移行することでした。

• ?アンケート: 回答を収集するためにエンドユーザーに表示されます。
• ?管理者ダッシュボード: 販売者がアンケートを設定し、分析を表示するために使用します。

実用的な顧客フィードバックを収集したい Shopify ストアのオーナーの方は、今すぐ Shopify App Store で Gojiberry を試してみてください!

移行の動機

CRA は以前は役に立ちましたが、現在は保守されておらず、その依存関係は時代遅れになっています。これにはいくつかの課題が生じました:

• ? 古いライブラリ: 非同期テストの処理に大幅な改善が導入された user-events v14 のような重要なライブラリに更新できませんでした。
• ? 遅いテスト: Jest テストは時間の経過とともに遅くなり、Vite と Vitest によって提供されるビルドとテストの高速化が必要でした。
• ⚖️ 一貫性のない動作: モノリポジトリ内の 2 つのプロジェクトでは、両方とも同じユーザー イベント バージョンを使用しており、1 つはすべてのアクションを act() でラップする必要がありましたが、もう 1 つは必要ありませんでした。この矛盾により混乱が生じ、開発が遅れました。

ユーザーイベント v14 の主な変更点

ユーザー イベント v14 の最大の改善点の 1 つは、すべてのインタラクション メソッドで await を使用する必要があることです。これにより、await waitFor でアクションをラップする必要がなくなり、テスト コードがクリーンになり、保守が容易になります。

前 (ユーザーイベント v13):

import { render, screen } from '@testing-library/react';
import userEvent from '@testing-library/user-event';
import MyComponent from './MyComponent';

test('updates state on click', async () => {
  render(<MyComponent />);

  userEvent.click(screen.getByRole('button'));

  await waitFor(() => {
    expect(screen.getByText('Updated state')).toBeInTheDocument();
  });
});

後 (ユーザーイベント v14):

import { render, screen } from '@testing-library/react';
import userEvent from '@testing-library/user-event';
import MyComponent from './MyComponent';

test('updates state on click', async () => {
  render(<MyComponent />);

  userEvent.click(screen.getByRole('button'));

  await waitFor(() => {
    expect(screen.getByText('Updated state')).toBeInTheDocument();
  });
});

この変更により、waitFor を使用して状態の変更を明示的に管理する必要がなくなり、テストが簡素化されます。ライブラリが自動的に処理するため、開発者は await waitFor をいつ含めるかについて考える必要がなくなりました。

ユーザー イベント v14 と Vitest の改善により、これらの問題の多くが解決され、よりクリーンで高速、より一貫した開発エクスペリエンスが提供されます。

検討された代替案

Vite を選択する前に、Next.js と Remix を評価しました。どちらも強力なフレームワークですが、コードベースとインフラストラクチャに大幅な変更が必要でした。

• Next.js とリミックス:

  • ? コードベースの再構成: どちらのフレームワークでも、規約に合わせてコードベースを再構成する必要があり、これは時間のかかるプロセスでした。
  • ?️ インフラストラクチャの変更: これらのフレームワークはシングル ページ アプリケーション (SPA) フレームワークではないため、これらを採用するには、展開およびホスティング インフラストラクチャの更新が必要になります。
  • ⚖️ ニーズに対して過剰です: これらはサーバー側のレンダリングとルーティングに優れた機能を提供しますが、これらの機能は私たちのユースケースには不要でした。

• Vite を選んだ理由:

  • ? 最小限のコード変更: Vite では既存のコードベースにほとんど変更を加える必要がなかったので、移行が簡単かつ効率的になりました。
  • ?️ Jest との 1 対 1 の互換性: Vitest は Jest と高い互換性があるため、最小限の調整でほとんどのテスト コードを再利用できます。
  • ⚡ パフォーマンスの向上: Vite ではビルド時間が短縮され、Vitest ではテスト実行が大幅に高速化されました。

Vite を選択することで、本格的なフレームワークを採用する複雑さを回避しながら、最新の軽量ビルド ツールのメリットを享受できました。

移行プロセス

モノリポには 2 つの個別の npm プロジェクトが含まれているため、移行には体系的に取り組みました。移行の実行方法は次のとおりです:

1. 小さいプロジェクトから始めます:

   • ?️ 最初に小規模なプロジェクトを移行することで、大規模なプロジェクトを危険にさらすことなく、潜在的な落とし穴を特定することができました。

2. 移行手順:
   
   各プロジェクトのプロセスは次の手順に従いました:

   • ? Vite への移行: CRA を Vite に置き換え、エラーを修正し、アプリが正しくビルドされて実行されることを確認します。
   • ? TypeScript エラーを修正: Vite ではより厳格な TypeScript ルールが導入され、コードベースの問題が明らかになりました。これらを修正するとコードの回復力が高まり、悪い習慣が減りました。
   • ✅ Vitest に移行: テストを Jest から Vitest に移行します。
   • ? テスト エラーを修正: Jest と Vitest が特定のシナリオを処理する方法の違いによって引き起こされる破損したテストに対処します。
   • ? user-events v14 にアップグレード: テスト ライブラリを更新し、壊れたテストを修正します。多くのテストでは手動による修正が必要でしたが、ほとんどの問題は、必要なときに React の状態変更を待たないなど、不適切なテスト ケースに起因していました。これは、テストのエラーを見つけて修正する貴重な機会でした。

3. より大きなプロジェクトに対して繰り返します:

   • ?小規模なプロジェクトの移行が成功した後、同じ手順をより大きなプロジェクトに適用しました。

直面した課題

• ? テストの失敗: Vitest への移行とユーザー イベント v14 へのアップグレードにより、多数のテストが失敗しました。ただし、これらの失敗により、React の状態変更に対する await 呼び出しの欠落など、テスト ケースの根本的な問題が明らかになりました。これらを修正することで、テストの精度と信頼性が向上しました。
• ?️ TypeScript の厳格さ: Vite のより厳格な TypeScript ルールにより、コード内に問題のあるパターンが明らかになりました。これらのエラーを修正するには余分な労力が必要でしたが、最終的にはよりクリーンで回復力のあるコードベースが完成しました。

結果

CRA から Vite への移行、および Vitest およびユーザー イベント v14 への移行により、開発ワークフローが大幅に改善されました。

• ⚡ ビルド時間とテスト時間の短縮: 移行後、テスト スイートは 30% 短縮された時間で完了し、CI パイプラインが大幅に高速化されました。
• ? 瞬時のホット リロード: 開発中の Vite のホット モジュール交換 (HMR) はほぼ瞬時に行われ、CRA よりも大幅に改善され、開発がよりシームレスかつ効率的になりました。
• ? テストの明確さと信頼性の向上: ユーザー イベント v14 と Vitest へのアップグレードにより、テストがよりクリーンで一貫性のあるものになりました。移行中に多くの誤ったテストが修正されたため、隠れたバグを見つけてコード全体の品質を向上させることができました。
• ?️ 弾力性のあるコードベース: Vite のより厳格な TypeScript ルールにより、コード内に改善の余地があるいくつかの領域が明らかになり、アプリがより堅牢になり、不正行為の可能性が減りました。

この移行はゲームチェンジャーであり、コードベースの信頼性を維持しながら、より高速に反復できるようになりました。

学んだ教訓

私たちの経験から得られるポイントをいくつか紹介します:

• ? 小規模から開始: リスクを軽減し、プロセスを改善するために、小規模なプロジェクトから始めます。
• ⏳ 壊れたテストを計画する: 一部のテスト ケースが壊れることを想定し、それらを修正する時間を割り当てます。こうした失敗によって、対処する価値のあるより深い問題が明らかになることがよくあります。
• ?️ より厳格なルールを採用する: 厳格な TypeScript ルールとフレームワークの違いは、最初は障害のように感じるかもしれませんが、最終的にはより良いコードベースにつながります。
• ? フレームワークを慎重に評価します: 既存のアーキテクチャと目標に合ったツールを選択します。

結論

CRA から Vite および Vitest への移行により、ワークフローが大幅に改善されました。より厳格な TypeScript ルールのおかげで、ビルドの高速化、ユーザー イベント v14 によるクリーンなテスト コード、およびより復元力の高いコードベースを享受できるようになりました。

この移行をよりスムーズにした主な要因の 1 つは、テスト駆動開発 (TDD) への初期投資でした。包括的なテストスイートを導入したことで、既存の機能を壊すことなく、自信を持って大規模な変更を加えることができました。

同様の移行を検討している場合、私たちの経験があなたの旅の指針となる貴重な洞察を提供することを願っています。

---

明日、2024 年 12 月 17 日の記事は、Gojiberry のプロダクト マーケティング マネージャー、Amee Xu による B2C から B2B への切り替え: マーケターの告白 となります。

ワノグループでは人材を募集しています！ご興味がございましたら、以下のリンクを使用して募集中のポジションをご確認ください:

求人 |ワノグループ

以上がReact CRA & Jest から Vite & Vitest への移行で得られた教訓の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。