안녕하세요! 오늘은 제가 CRA(Craco)에서 Vite로 전환하게 된 경험에 대해 나누어 보려고 합니다.
제가 처음에 CRA(Create React App)와 Craco(Create React App Configuration Override)를 선택한 이유는, 프로젝트 준비 기간이 짧았기 때문에 빠르게 시작할 수 있는 환경이 필요했기 때문입니다. CRA는 React 프로젝트의 초기 단계에 필요한 다양한 라이브러리, Webpack, ESLint 설정 등을 이미 포함하고 있는 보일러플레이트로, ES6 이상의 문법과 CSS 후처리 등의 개발 환경을 자동으로 설정해 주어 매우 편리합니다.
그러나 Craco를 사용하면서 몇 가지 단점을 경험했습니다. 특히 프로그램의 실행 속도가 느려서 개발 효율이 많이 떨어지는 것을 느꼈습니다. Craco를 통해 절대 경로 설정과 같은 추가적인 커스터마이징은 가능했지만, 이러한 설정이 때로는 복잡성을 더하고 빌드 시간을 증가시키는 원인이 되었습니다.
이러한 이유로 저는 Vite로 전환하기로 결정했습니다. Vite는 현대적인 프런트엔드 개발을 위한 새로운 빌드 도구로, 빠른 핫 모듈 리플레이스먼트(HMR)와 진정한 ES 모듈을 이용한 개발 서버를 제공합니다. 이는 개발 중에 애플리케이션의 변경 사항을 즉각적으로 반영할 수 있게 해, 개발 속도를 대폭 향상시킵니다.
또한, Vite는 설정이 매우 간단하며, 필요한 경우 Rollup을 통한 고급 설정도 지원합니다. 이는 크게 두 가지 측면에서 이점을 제공합니다: 첫째, 개발자가 더 직관적이고 단순한 방식으로 프로젝트를 구성할 수 있게 해주며, 둘째, 빌드 속도가 향상되어 더 효율적인 작업이 가능합니다.
결론적으로, Vite로 전환하면서 개발 환경의 효율성과 속도가 크게 향상되었고, 이는 프로젝트의 전반적인 생산성 증대로 이어졌습니다. 이러한 이유로 Vite는 현대 웹 개발에 매우 적합한 도구로 자리 잡았습니다.
Craco 란?
Craco(Create React App Configuration Override)는 Create React App(CRA)의 기본 설정을 사용자 정의할 수 있게 해주는 도구입니다. 그러나 Craco를 사용하는 경우 프로젝트가 무거워지는 이유 중 하나는 eject 과정과 관련이 있습니다.
CRA를 사용할 때, 프로젝트의 구성이나 웹팩(Webpack) 설정을 변경하고 싶다면 일반적으로 eject 명령어를 사용합니다. 이 eject는 CRA에서 제공하는 내장 구성을 모두 프로젝트 내부로 추출해, 사용자가 직접 관리할 수 있도록 합니다. 하지만 이 과정은 매우 복잡하며, 한 번 eject를 실행하면 되돌릴 수 없기 때문에 많은 개발자들이 주저하게 됩니다.
Craco는 이러한 eject의 필요성을 줄이기 위해 만들어졌습니다. 사용자가 CRA의 기본 구성을 eject하지 않고도 수정할 수 있게 해주는 것이죠. 그러나 이를 위해 Craco는 CRA의 기본 구성 위에 추가적인 추상화 층을 더합니다. 이로 인해 웹팩과 같은 도구들의 설정을 간접적으로 조작하게 되며, 이는 프로젝트의 복잡성을 증가시키고 결과적으로 빌드 프로세스가 더 무거워지고 느려질 수 있습니다.
즉, Craco는 eject를 피하면서도 사용자 정의를 가능하게 하는 유용한 도구이지만, 그 과정에서 원래의 CRA 구성을 덮어쓰고 추가적인 처리 단계를 거치게 되므로 전체 프로젝트의 무게와 복잡성이 증가하는 원인이 됩니다. 이러한 이유로 일부 개발자들은 더 가벼운 대안을 찾아 Vite 같은 다른 빌드 도구로 전환하기도 합니다.
숨긴처리내용을 보고 싶다면,
npm run eject
yarn eject
를 하면되지만, CRA 공식 홈페이지에서는 권장하지 않는 방법입니다.
eject을 사용하는 이유는 CRA가 숨겨놓은 파일들을 원하는대로 프로젝트에 맞게 커스터마이징 하고 싶을 때 사용합니다.
Vite, 내가 사용하는 가장 큰 이유
Craco에서 Vite로 전환하고 싶은 가장 큰 이유는, Craco를 사용하면서 서버를 시작할 때마다, 그리고 코드에 수정 사항이 있을 때마다 화면이 나타나기까지 많은 시간이 소요되는 것에 대해 큰 답답함을 느꼈습니다. 이러한 지연은 우리의 작업 효율을 떨어뜨리고 개발 과정에서의 만족도를 크게 저하시킵니다.
Vite로 변경하고자 하는 가장 큰 동기 중 하나는 바로 이런 지속적인 지연 문제를 해결하기 위함입니다. Vite는 즉각적인 서버 시작과 빠른 모듈 교체를 통해 개발 시간을 대폭 단축시킬 수 있습니다. 이는 우리가 더 빠르고 효율적으로 작업할 수 있게 도와주며, 개발 과정에서의 만족도를 높여주지 않을까하는 기대감입니다. :)
Vite의 장점으로는 다음과 같은 장점들이 있습니다.
모듈 처리 방식의 차이: Vite는 개발 중에 네이티브 ES 모듈(ESM)을 사용하여 직접 브라우저로 파일을 제공합니다. 이는 파일이 필요할 때마다 바로 제공될 수 있게 해, 서버 시작 시 모든 코드를 번들링할 필요가 없습니다. 반면, Craco는 CRA의 Webpack 기반 설정을 사용하여 개발 서버를 시작할 때 모든 소스 코드를 미리 번들링해야 합니다. 이 과정은 시간이 많이 소요될 수 있습니다
종속성 사전 번들링: Vite는 esbuild를 이용해 종속성을 매우 빠르게 사전 번들링합니다. esbuild는 Go로 작성되어 JavaScript 기반의 번들러보다 훨씬 빠르며, 이는 Vite가 종속성을 처리하는 속도를 대폭 향상시킵니다. Craco를 사용할 때는 종속성 처리가 느릴 수 있으며, 특히 크고 복잡한 라이브러리를 다룰 때 더욱 그렇습니다
온디맨드 코드 제공: Vite는 개발 중에 필요한 코드만 브라우저로 전송합니다. 즉, 사용자가 실제로 필요로 하는 코드만 로드하여 처리하기 때문에 초기 개발 서버의 부하를 크게 줄일 수 있습니다. 이에 비해 Craco와 같은 전통적인 번들러를 사용하는 경우, 서버 시작 시 모든 코드를 처리해야 하므로 시간이 더 걸립니다.
HMR(핫 모듈 교체) 최적화: Vite의 HMR은 개발 중 코드 변경이 빠르게 반영되도록 설계되어 있어, 개발 효율성을 높입니다. Craco를 포함한 기존의 도구들에서는 HMR 처리가 비교적 느리고, 애플리케이션 규모가 클수록 성능 저하가 발생하기 쉽습니다.
이러한 이유로 Vite는 서버를 시작하고 개발을 진행하는 데 있어서 Craco보다 월등한 성능을 제공하며, 이는 개발자의 생산성을 크게 향상시키는 결과를 가져옵니다.
Vite로 전환하기 전에 CRA 속도 측정
아직 배포는 하기 전이기 때문에, 빌드시간을 비교하려고 한다.
Vite와 Craco를 비교하면서 구체적인 수치는 우리가 기술 선택에 있어서 객관적인 근거를 가질 수 있게 도와주기 때문에 빌드시간이라는 수치를 비교하려고 한다.
웹팩으로 프로젝트를 빌드 했을 때 빌드 완료까지 걸린시간을 측정하려고한다.
speed-measure-webpack-plugin은 웹팩 빌드 시간을 측정하고, 각 로더 및 플러그인의 실행 시간을 분석할 수 있는 플러그인입니다.
npm install --save-dev speed-measure-webpack-plugin
다음과 같이 설치를 하고
craco.config.js파일에 다음과 같이 적용하면된다.
// eslint-disable-next-line import/no-extraneous-dependencies
const SpeedMeasurePlugin = require('speed-measure-webpack-plugin');
const path = require('path');
const smp = new SpeedMeasurePlugin();
module.exports = {
webpack: {
configure: webpackConfig =>
smp.wrap({
...webpackConfig,
module: {
...webpackConfig.module,
rules: [
{
test: /\.svg$/,
use: ['@svgr/webpack'],
},
...(webpackConfig.module.rules || []),
],
},
resolve: {
...webpackConfig.resolve,
alias: {
...webpackConfig.resolve?.alias,
'@common': path.resolve(__dirname, 'src/common'),
'@components': path.resolve(__dirname, 'src/components'),
'@UI': path.resolve(__dirname, 'src/components/UI'),
'@images': path.resolve(__dirname, 'src/common/images'),
'@pages': path.resolve(__dirname, 'src/pages'),
'@utils': path.resolve(__dirname, 'src/utils'),
'@recoil': path.resolve(__dirname, 'src/utils/recoil'),
'@layout': path.resolve(__dirname, 'src/components/UI/layout'),
'@apis': path.resolve(__dirname, 'src/apis'),
},
},
}),
},
};
craco로 적용하려고 했을때 골치아픈 문제가 있는데,
https://github.com/stephencookdev/speed-measure-webpack-plugin#readme
GitHub - stephencookdev/speed-measure-webpack-plugin: ⏱ See how fast (or not) your plugins and loaders are, so you can optimis
⏱ See how fast (or not) your plugins and loaders are, so you can optimise your builds - stephencookdev/speed-measure-webpack-plugin
github.com
https://github.com/stephencookdev/speed-measure-webpack-plugin/issues/164
speed-measure-webpack-plugin does not work with create-react-app · Issue #164 · stephencookdev/speed-measure-webpack-plugin
Thanks for building this plugin. It would be super useful to make it working with create-react-app, since this has been growing by a large factor, and becomes the de-facto. Error: Below is the erro...
github.com
위에 공식홈페이지랑, issue 사항을 보면 해결 가능하다.
다음과 같이 측정을해봤고, 이제 Vite를 적용할것이다.
'문제 해결하기 - FE' 카테고리의 다른 글
react-hook-form 컴포넌트 의존성 관리하기 (0) | 2024.04.05 |
---|---|
TanStack query InfiniteQuery 사용 중 발생한 캐싱 문제 (0) | 2024.03.07 |
husky + lint-staged가 필요한 이유 (prettier + eslint) (1) | 2024.03.06 |
recoil -> Tanstack-query 무한 스크롤 구현 (0) | 2024.03.05 |
Recoil / Tanstack query 역할 분리하기 (0) | 2024.03.05 |