1. Vite
빠르다.
개발 서버에서의 번들링
번들링을 통해 네이티브에서 원하는 모듈을 불러오기 위한 요청 횟수를 극적으로 줄여 모듈의 병목 이슈를 해결할 수 있있었지만, 번들링은 일종의 우회적인 방법으로 자바스크립트의 모듈 시스템을 풀이한 방식이다.
개발서버에서도 마찬가지로 런타임에 제품을 올리기 위해 빌드를 하는데, 번들러에서 열심히 번들링하고 결과물을 로드하는데까지 적게는 수십초가 걸린다.
~$ yarn dev
$ webpack serve...
<i> [webpack-dev-server] Project is running at:
<i> [webpack-dev-server] Loopback: http://localhost:3000/, http://127.0.0.1:3000/
<i> [webpack-dev-server] Content not from webpack is served from '.../public' directory
<i> [webpack-dev-server] 404s will fallback to '/index.html'
<i> [webpack-dev-middleware] wait until bundle finished: /
...
webpack 5.75.0 compiled successfully in 18337 ms
코드를 수정하고 다시 빌드할때도 HMR 도움을 받지만, 몇초는 기다려야 하는 것이 사실이다. Vite는 번들링이 개발 경험에 마이너스 요소로 자리잡고 있다는 점을 해결해야할 문제로 제시한다.
Native ESM
잠시 Vite에서 제공하는 스크립트를 통해 생성된 프로젝트의 index.html
를 보면 스크립트 태그를 통해 메인 모듈을 불러오도록 되어 있는 것을 확인할 수 있다.
<div id="app"></div>
<script type="module" src="./main.js"></script>
Vite는 다시금 네이티브에서 ES 모듈을 해석할 수 있다는 점에 집중한다. 기존 네이티브에서 모듈을 처리하는 방식이 개발속도를 극적으로 빠르게 끌어올려 주었다고 설명한데, 굳이 번들링하지 않아도 네이티브가 자바스크립트 파일을 파싱하고, 임포트 구문에 대해 HTTP를 통해 원하는 모듈에 대한 요청을 보내서 모듈을 받는데, 이 과정이 개발 서버에서 상당히 가벼운 처리로 네이티브 영역에서 수행된다는 것이다.
위에서 언급한 index.html
은 public
폴더가 아닌 최상단에 위치하는 것을 볼 수 있는데 이 또한 별다른 번들링 없이 추가적인 번들링없이 애플리케이션의 진입점으로 명시하기 위함이라고 한다.
번들링을 완전 배제하는가
그렇지 않다. Vite는 공식문서에서 알 수 있듯 ESM 말고도 기존 번들러들이 제공하는 기능을 대부분 지원하고 있다. ESM은 개발 단계의 번들링으로 인한 이슈를 해결하기 위한 방식으로 채택하고 있다. 프러덕션 레벨의 빌드는 타 번들러들과 동일하게 번들링을 하고 있다.
프러덕션 레벨에서는 여전히 번들링되지 않은 ESM을 가져오는 것이 중첩된 import
로 인한 네트워크 통신 횟수가 늘어나는 것이 비효율적임을 인식하고 있다. 추가적으로 번들링 단계에서 트리 쉐이킹, 청크 분할 등 더 나은 캐싱을 위해서 번들링을 사용하는 것이 좋다고 설명한다.
추가적으로, 개발 서버에서도 큰 의존성 모듈에 대해 사전 번들링을 진행한다. 가령, npm 패키지가 담긴 node_modules
디렉토리의 자식들이 그 대상인데,
CommonJS 및 UMD* 모듈을 ES 모듈로 변환되며,
/node_modules/.vite/deps/my-dep.js?v=f3sf2ebd
와 같이 URL을 이용해 ESM을 지원하는 브라우저에서 모듈을 가져올 수 있도록import
구문을 수정
해서 ESM에서 지원하는 모듈로 변경한다. 사전 번들링된 모듈들은 모두 반드시 node_modules/.vite
디렉터리 내에 캐시가 이루어진다. (패키지 매니저의 lock 파일, vite.config, NODE_ENV) 가 수정되었을때만 다시 번들링한다.
Last updated