從 React CRA 和 Jest 遷移到 Vite 和 Vitest 的經驗教訓-js教程-PHP中文網

Lessons Learned Migrating from React CRA & Jest to Vite & Vitest

本文適用於 EDOCODE 2024 年降臨節日曆，於 2024 年 12 月 16 日發布。

上一篇文章由 EDOCODE 產品經理 Taiji Yamada 撰寫：使用 Notion Webhooks 和無代碼工具「Make」的自動化電子郵件系統（文章為日文）。

另外，請查看我們母公司集團公司的和之降臨節日曆！

簡介

我們的應用程式 Gojiberry 是一款 Shopify 調查應用程序，可幫助商家從客戶那裡收集有價值的回饋。

從一開始，我們就透過測試驅動開發 (TDD) 來建立 Gojiberry，以確保我們的應用程式沒有錯誤，並且我們可以在不破壞現有功能的情況下自信地發布新功能。這個基礎使我們能夠進行大規模的更改，例如從 Create React App (CRA) 遷移到 Vite，同時將幹擾降至最低。

當 CRA 被棄用並且它的依賴項變得過時時，我們決定是時候升級到現代構建工具，以更好地支援我們不斷增長的應用程式。我們的程式碼庫規模較大，增加了一些複雜性，但事實證明，轉向 Vite 的努力是值得的。

我們的目標是遷移我們的兩個 React 專案：

？調查：向最終用戶顯示以收集他們的回應。
？管理儀表板：商家用來設定調查和查看分析。

如果您是 Shopify 店主，希望收集可行的客戶回饋，請立即在 Shopify 應用程式商店中試用 Gojiberry！

遷移的動機

CRA 過去為我們提供了很好的服務，但它不再被維護，而且它的依賴項也已經過時了。這帶來了一些挑戰：

？ 過時的庫：我們無法更新到用戶事件 v14 等關鍵庫，它在處理非同步測試方面引入了重大改進。
？ 緩慢的測試：隨著時間的推移，Jest 測試變得越來越慢，我們希望 Vite 和 Vitest 提供更快的建置和測試時間。
⚖️ 不一致的行為：在我們的monorepo 中的兩個項目中，兩個項目都使用相同的用戶事件版本，一個需要使用act() 包裝每個操作，而另一個則不需要。這種不一致造成了混亂並減慢了開發速度。

使用者事件 v14 的主要變化

使用者事件 v14 中最大的改進之一是要求對所有互動方法使用 wait。這消除了在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 和 Remix：
- ？ 程式碼庫重組：這兩個框架都要求我們重組程式碼庫以適應它們的約定，這將是一個耗時的過程。
- ?️ 基礎設施變更：這些框架不是單頁應用程式 (SPA) 框架，因此採用它們需要更新我們的部署和託管基礎設施。
- ⚖️ 對我們的需求來說太過分了：雖然它們為伺服器端渲染和路由提供了出色的功能，但這些功能對於我們的用例來說是不必要的。
為什麼我們選Vite：
- ？ 最少的程式碼更改：Vite 幾乎不需要對我們現有的程式碼庫進行任何更改，從而使轉換簡單而有效率。
- ?️ 與 Jest 一對一相容性：由於 Vitest 與 Jest 高度相容，我們可以透過最少的調整重複使用大部分測試程式碼。
- ⚡ 效能改善：Vite 提供了更快的建置時間，Vitest 顯著加快了測試執行速度。

透過選擇 Vite，我們避免了採用成熟框架的複雜性，同時獲得了現代輕量級建構工具的好處。

遷移過程

我們有系統地進行了遷移，因為我們的 monorepo 包含兩個獨立的 npm 專案。以下是我們執行遷移的方式：

從較小的專案開始：
- ？ ️ 首先遷移較小的專案使我們能夠識別潛在的陷阱，而不會冒較大專案的風險。
遷移步驟：

每個專案的流程都遵循以下步驟：
- ？ 遷移到 Vite：用 Vite 取代 CRA，修復任何錯誤，並確保應用程式正確建置和運行。
- ？ 修正 TypeScript 錯誤：Vite 引入了更嚴格的 TypeScript 規則，暴露了程式碼庫中的問題。修復這些問題使程式碼更具彈性並減少了不良做法。
- ✅ 遷移到 Vitest：將測試從 Jest 轉換到 Vitest。
- ？ 修正測試錯誤：解決由於 Jest 和 Vitest 處理某些場景的方式差異而導致的任何損壞的測試。
- ？ 升級到使用者事件 v14：更新測試庫並修復損壞的測試。雖然許多測試需要手動修復，但大多數問題源自於不正確的測試案例，例如在必要時不等待 React 狀態變更。這是在我們的測試中發現並糾正錯誤的寶貴機會。
對更大的項目重複：
- ？成功遷移較小的專案後，我們將相同的步驟應用於較大的專案。

遇到的挑戰

？ 損壞的測試：遷移到 Vitest 並升級到 user-events v14 導致大量測試失敗。然而，這些失敗揭示了我們的測試案例中的潛在問題，例如缺少對 React 狀態變更的等待呼叫。解決這些問題提高了我們測試的準確性和可靠性。
?️ TypeScript 嚴格性：Vite 更嚴格的 TypeScript 規則暴露了我們程式碼中的有問題的模式。雖然修復這些錯誤需要額外的努力，但最終結果是一個更乾淨、更有彈性的程式碼庫。

結果

從 CRA 遷移到 Vite，以及向 Vitest 和用戶事件 v14 的過渡，為我們的開發工作流程帶來了重大改進：

⚡ 更快的建造和測試時間：遷移後，我們的測試套件現在可以在減少30% 的時間內完成，顯著加快了我們的CI 管道。
？ 即時熱重載：Vite 在開發過程中的熱模組替換（HMR）幾乎是瞬時的，相對於 CRA 來說是一個巨大的改進，使開發更加無縫和高效。
？ 提高了測試清晰度和可靠性：升級到 user-events v14 和 Vitest 帶來了更乾淨、更一致的測試。遷移過程中修復了許多錯誤的測試，幫助我們發現隱藏的錯誤並提高整體程式碼品質。
?️ 彈性程式碼庫：Vite 更嚴格的 TypeScript 規則暴露了我們程式碼中需要改進的幾個領域，使應用程式更加健壯並減少了不良實踐的可能性。

遷移改變了遊戲規則，使我們能夠更快地迭代，同時保持對程式碼庫的信心。