Vite Migration
기능구현을 제외하고 본 프로젝트 코드의 목표는 1차적으로 Vite 적용 이라고 해도 과언이 어니었다. 시작은 코드 쓰레기 더미였던 외주코드를 걷어내는 것이었지만, 코드를 정리하고 보니 Vite로 넘어갈 수도 있겠다 싶었다.
프로젝트에 자체 UI컴포넌트를 모두 적용한 직후 나는 본 프로젝트에 Vite 적용을 검토하기 시작했다. 대략 아래와 같은 순서로 작업을 진행하기로 하였다.
- Vue3 + Vite 기반의 빈 프로젝트 생성
- 생성된 Vite 기반 프로젝트에 내 프로젝트 코드 파일들을 복사
- webpack 전용 코드를 vite 전용 코드로 컨버팅
- i18n 마이그레이션
- 빌드테스트
- QA환경 배포테스트
1, 2 단계는 어렵지 않게 진행되었다. Vite 기반 프로젝트 또한 Vue3 파일이 모두 호환되었으므로 vue 및 vuex 사용에 문제가 발견되지는 않았던 것으로 기억한다.
3단계는 사실 Vite 적용을 위한 계획단계에 포함되지는 않았었는데, 기존 프로젝트에 webpack(vue cli) 전용 코드가 포함되어있는지 몰랐었기 때문이었다. 예를 들면 다음과 같은 것들이 있었다.
- .env에 정의하는 환경변수명이 달라서 변경해 주어야 했음
VUE_APP_ > VITE_ - i18n 용으로 작성된 json파일을 로드하기 위해 사용했던 require.context 대신 import.meta.glob 을 사용해야 했음
- 두 함수간 사용법이 달라서 depth별로 파일 분리가 되어있던 webpack 기반 구조 대신 하나의 통합된 파일로 변경처리 했음
- 예) ko/a.json, ko/menu/b.json 형태의 분리된 파일을 ko.json 과 같이 하나의 파일로 합침
- 기존에는 vue-router의 js 파일에서 페이지용 vue 파일을 동적 로드했었으나 vite에서는 불가능하여 정적로드 (최상단 import문 사용) 방식으로 변경했음
그리고 i18n의 경우는 vite용 플러그인이 별도로 존재하여 해당 플러그인이 동작하도록 구조를 변경했어야 했다. 기억상 본 플러그인 예제코드를 아무리 수정해봐도 복수개의 locale.json 파일을 로딩할 수 없어서 하나의 파일로 합쳤던 것이기도 했다.
생각보다 4번 i18n 통합 작업이 어려웠었다. Vite 구조상 locale 파일을 분리적용할 수 있는것인지는 아직도 잘 모르겠다. 그래서 분리되어있던 locale 파일을 하나로 합칠지 말지를 고민하는데 시간이 많이 소요되었던 것 같다. 언어파일을 분리하는데에도 공수가 많이 들어갔었는데 다시 합치려니 고민이 많이 되었다.
i18n 작업이 마무리 된 뒤 바로 빌드 및 배포테스트를 진행할 수 있었다.
스타일 코드 수정
빌드 및 배포테스트를 해 보니, v-calendar 의 스타일이 이상하게도 잘 적용되지 않는 문제가 있었다. .vue 파일에 작성해 두었던 style scoped 에 작성된 v-calendar 커스터마이징 코드가 vite가 빌드를 하면서 삭제해 버리는 것 같았다. 그래서 일단 v-calendar 커스터마이징이 필요한 스타일은 별도의 css파일로 분리하여 전역 import 하는 방식으로 수정하였다.
마이그레이션 완료
그리고 몇 가지 자잘한 문제들을 수정하고 나니 내 프로젝트 및 신규 서비스 프로젝트까지도 정상적으로 Vite로 전환할 수 있었다.
배운점
외부 의존성을 최소화 하자
Vite Migration을 진행하면서 느끼는 것인데, 최대한 외부 라이브러리의 사용을 줄일수록 전환이 쉬워진다는 점이다. 자체 UI컴포넌트를 구현한 덕분에 Antdv 의 Vite migration을 검토할 필요가 없었으며, 자체 구현한 UI컴포넌트는 순수하게 SFC로 구현되어서 그런지 별도의 수정 없이 정상적으로 동작하였다. 그리고 Vite Migration 전에 최대한 라이브러리 의존성 등을 제거하여 Migration 지연이 발생하지 않았던 것 같다.
(참고로 기존에는 외주에서 작성한 코드 및 Antdv 라이브러리 등으로 인해 jsx 코드가 사용되었으나 자체 UI컴포넌트로 전환하면서 jsx 지원도 제거할 수 있었고, 기타 구현에 불필요한 라이브러리를 최대한 줄였었다.)
끝