React CRA 및 Jest에서 Vite 및 Vitest로 마이그레이션하면서 배운 교훈

이 글은 2024년 12월 16일 발행된 EDOCODE Advent Calendar 2024에 대한 것입니다.

이전 기사는 EDOCODE: Notion Webhooks 및 노코드 도구 "Make"를 사용한 자동 이메일 시스템의 제품 관리자인 Taiji Yamada가 작성했습니다(기사는 일본어로 작성됨).

또한, 모그룹 회사의 Wano Advent Calendar도 확인해보세요!

소개

저희 앱인 Gojiberry는 판매자가 고객으로부터 귀중한 피드백을 수집하는 데 도움이 되는 Shopify 설문조사 앱입니다.

처음부터 우리는 앱에 버그가 없고 기존 기능을 손상시키지 않으면서 자신 있게 새로운 기능을 출시할 수 있도록 테스트 중심 개발(TDD)을 사용하여 Gojiberry를 구축했습니다. 이 기반을 통해 CRA(Create React App)에서 Vite로 마이그레이션하는 등의 대규모 변경을 최소한의 중단으로 수행할 수 있었습니다.

CRA가 더 이상 사용되지 않고 종속 항목이 오래 되었을 때 우리는 성장하는 앱을 더 잘 지원할 수 있는 최신 빌드 도구로 업그레이드해야 할 때라고 결정했습니다. 우리 코드베이스의 크기가 커서 약간의 복잡성이 추가되었지만 Vite로의 전환은 노력할 가치가 있는 것으로 입증되었습니다.

우리의 목표는 두 개의 React 프로젝트를 마이그레이션하는 것이었습니다.

• ? 설문조사: 응답을 수집하기 위해 최종 사용자에게 표시됩니다.
• ? 관리 대시보드: 판매자가 설문조사를 구성하고 분석을 보는 데 사용됩니다.

실행 가능한 고객 피드백을 수집하려는 Shopify 스토어 소유자라면 지금 Shopify 앱 스토어에서 Gojiberry를 사용해 보세요!

이주 동기

CRA는 과거에 우리에게 많은 도움이 되었지만 더 이상 유지 관리되지 않으며 종속성이 오래되었습니다. 이로 인해 몇 가지 문제가 발생했습니다.

• ? 오래된 라이브러리: 비동기 테스트 처리를 크게 개선한 user-events v14와 같은 중요한 라이브러리로 업데이트할 수 없었습니다.
• ? 느린 테스트: Jest 테스트는 시간이 지남에 따라 느려지고 있었고 우리는 Vite 및 Vitest가 제공하는 더 빠른 빌드 및 테스트 시간을 원했습니다.
• ⚖️ 일관되지 않은 동작: 동일한 사용자 이벤트 버전을 사용하는 모노레포의 두 프로젝트에서 하나는 모든 작업을 act()로 래핑해야 했지만 다른 하나는 그렇지 않았습니다. 이러한 불일치로 인해 혼란이 발생하고 개발 속도가 느려졌습니다.

사용자 이벤트 v14의 주요 변경 사항

사용자 이벤트 v14의 가장 큰 개선 사항 중 하나는 모든 상호 작용 방법에 대해 대기를 사용해야 한다는 것입니다. 이렇게 하면 wait For에서 작업을 래핑할 필요가 없어 테스트 코드가 더 깔끔하고 유지 관리가 쉬워집니다.

이전(사용자 이벤트 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></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></mycomponent>);

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

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

이 변경 사항은 waitFor를 사용하여 상태 변경을 명시적으로 관리할 필요성을 제거하여 테스트를 단순화합니다. 라이브러리가 이를 자동으로 처리하므로 개발자는 더 이상 waitFor를 언제 포함할지 생각할 필요가 없습니다.

사용자 이벤트 v14 및 Vitest의 개선 사항은 이러한 많은 문제를 해결하여 더욱 깨끗하고 빠르며 일관된 개발 환경을 제공합니다.

고려된 대안

Vite를 선택하기 전에 Next.js와 Remix를 평가했습니다. 둘 다 강력한 프레임워크이지만 코드베이스와 인프라에 상당한 변경이 필요했습니다.

• Next.js 및 리믹스:

  • ? 코드베이스 재구성: 두 프레임워크 모두 해당 규칙에 맞게 코드베이스를 재구성해야 했으며 이는 시간이 많이 걸리는 프로세스였습니다.
  • ?️ 인프라 변경: 이러한 프레임워크는 SPA(단일 페이지 애플리케이션) 프레임워크가 아니므로 이를 채택하려면 배포 및 호스팅 인프라를 업데이트해야 합니다.
  • ⚖️ 우리 요구 사항에 대한 과잉: 서버 측 렌더링 및 라우팅을 위한 훌륭한 기능을 제공하지만 이러한 기능은 우리 사용 사례에는 필요하지 않았습니다.

• Vite를 선택한 이유:

  • ? 최소한의 코드 변경: Vite는 기존 코드베이스를 거의 변경할 필요가 없어 전환이 간단하고 효율적입니다.
  • ?️ Jest와의 1:1 호환성: Vitest가 Jest와 매우 호환되므로 최소한의 조정만으로 대부분의 테스트 코드를 재사용할 수 있습니다.
  • ⚡ 성능 개선: Vite는 더 빠른 빌드 시간을 제공했고 Vitest는 테스트 실행 속도를 크게 높였습니다.

Vite를 선택함으로써 우리는 완전한 프레임워크를 채택하는 데 따른 복잡성을 피하는 동시에 현대적이고 가벼운 빌드 도구의 이점을 누릴 수 있었습니다.

마이그레이션 프로세스

우리의 모노레포에는 두 개의 별도 npm 프로젝트가 포함되어 있으므로 마이그레이션에 체계적으로 접근했습니다. 마이그레이션을 실행한 방법은 다음과 같습니다.

1. 작은 프로젝트부터 시작하세요:

   • ?️ 먼저 소규모 프로젝트를 마이그레이션함으로써 대규모 프로젝트에 대한 위험을 감수하지 않고도 잠재적인 함정을 식별할 수 있었습니다.

2. 마이그레이션 단계:
   
   각 프로젝트의 프로세스는 다음 단계를 따랐습니다.

   • ? Vite로 마이그레이션: CRA를 Vite로 교체하고, 오류를 수정하고, 앱이 올바르게 빌드 및 실행되는지 확인하세요.
   • ? TypeScript 오류 수정: Vite는 더 엄격한 TypeScript 규칙을 도입하여 코드베이스에 문제를 노출시켰습니다. 이러한 문제를 해결하면 코드의 탄력성이 향상되고 나쁜 관행이 줄어듭니다.
   • ✅ Vitest로 마이그레이션: Jest에서 Vitest로 전환 테스트.
   • ? 테스트 오류 수정: Jest와 Vitest가 특정 시나리오를 처리하는 방식의 차이로 인해 발생한 손상된 테스트를 해결합니다.
   • ? user-events v14로 업그레이드: 테스트 라이브러리를 업데이트하고 손상된 테스트를 수정하세요. 많은 테스트에 수동 수정이 필요했지만 대부분의 문제는 필요할 때 React 상태 변경을 기다리지 않는 등 잘못된 테스트 사례에서 발생했습니다. 이는 테스트에서 오류를 발견하고 수정할 수 있는 귀중한 기회였습니다.

3. 대규모 프로젝트에 대해 반복:

   • ? 소규모 프로젝트를 성공적으로 마이그레이션한 후 더 큰 프로젝트에도 동일한 단계를 적용했습니다.

도전과제

• ? 깨진 테스트: Vitest로 마이그레이션하고 user-events v14로 업그레이드하면 수많은 테스트 실패가 발생했습니다. 그러나 이러한 실패로 인해 React 상태 변경에 대한 대기 호출 누락과 같은 테스트 사례의 근본적인 문제가 드러났습니다. 이러한 문제를 해결하여 테스트의 정확성과 신뢰성이 향상되었습니다.
• ?️ TypeScript 엄격함: Vite의 더 엄격한 TypeScript 규칙은 우리 코드에서 문제가 있는 패턴을 노출했습니다. 이러한 오류를 수정하려면 추가 노력이 필요했지만 최종 결과는 더 깔끔하고 탄력적인 코드베이스였습니다.

결과

CRA에서 Vite로의 마이그레이션과 Vitest 및 user-events v14로의 전환으로 개발 워크플로가 크게 개선되었습니다.

• ⚡ 더 빨라진 빌드 및 테스트 시간: 마이그레이션 후 테스트 스위트는 이제 30% 더 짧은 시간으로 완료되어 CI 파이프라인 속도가 크게 향상되었습니다.
• ? 즉시 핫 리로드: 개발 중 Vite의 핫 모듈 교체(HMR)는 거의 즉각적으로 이루어지며, 이는 CRA에 비해 크게 개선되어 개발을 더욱 원활하고 효율적으로 만듭니다.
• ? 테스트 명확성 및 신뢰성 향상: user-events v14 및 Vitest로 업그레이드하여 더욱 깨끗하고 일관된 테스트가 가능해졌습니다. 마이그레이션 중에 많은 잘못된 테스트가 수정되어 숨겨진 버그를 찾아내고 전반적인 코드 품질을 향상시키는 데 도움이 되었습니다.
• ?️ 복원력 있는 코드베이스: Vite의 더욱 엄격한 TypeScript 규칙은 코드 개선이 필요한 여러 영역을 노출하여 앱을 더욱 강력하게 만들고 나쁜 관행이 발생할 가능성을 줄였습니다.

마이그레이션은 코드베이스에 대한 자신감을 유지하면서 더 빠르게 반복할 수 있게 해 주면서 게임의 판도를 바꿔 놓았습니다.

배운 교훈

다음은 경험에서 얻은 몇 가지 시사점입니다.

• ? 작게 시작: 위험을 줄이고 프로세스를 개선하려면 소규모 프로젝트부터 시작하세요.
• ⏳ 깨진 테스트 계획: 일부 테스트 사례가 깨질 것으로 예상하고 이를 수정하는 데 시간을 할당합니다. 이러한 실패는 해결해야 할 더 깊은 문제를 드러내는 경우가 많습니다.
• ?️ 더 엄격한 규칙 수용: 더 엄격한 TypeScript 규칙과 프레임워크 차이가 처음에는 장애물처럼 느껴질 수 있지만 궁극적으로는 더 나은 코드베이스로 이어집니다.
• ? 프레임워크를 신중하게 평가하세요: 기존 아키텍처 및 목표에 맞는 도구를 선택하세요.

결론

CRA에서 Vite 및 Vitest로 마이그레이션하여 작업 흐름이 크게 개선되었습니다. 이제 우리는 더욱 엄격한 TypeScript 규칙 덕분에 더욱 빠른 빌드, user-events v14를 통한 더욱 깔끔한 테스트 코드, 더욱 탄력적인 코드베이스를 누릴 수 있습니다.

이 전환을 더욱 원활하게 만든 주요 요인 중 하나는 테스트 중심 개발(TDD)에 대한 초기 투자였습니다. 포괄적인 테스트를 통해 우리는 기존 기능을 손상시키지 않으면서 자신 있게 대규모 변경을 수행할 수 있었습니다.

유사한 마이그레이션을 고려하고 계시다면 우리의 경험이 귀하의 여정을 안내하는 귀중한 통찰력이 되기를 바랍니다.

---

2024년 12월 17일 내일, 기사는 Gojiberry의 제품 마케팅 관리자인 Amee Xu의 B2C에서 B2B로 전환: 마케팅 담당자의 고백입니다.

와노그룹에서 채용을 진행합니다! 관심이 있으시면 아래 링크를 통해 채용 공고를 확인해 보세요:

채용정보 | 와노그룹

위 내용은 React CRA 및 Jest에서 Vite 및 Vitest로 마이그레이션하면서 배운 교훈의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!