Vite 가볍게 살펴보기

Vite는 Unbundled Development 도구로써 기존 webpack이나 rollup과 같은 기존 번들러와는 개념이 약간 다릅니다. 이번 포스트에서는 기존에 인식되고 있는 Bundler의 단점을 간단하게 살펴보고, 이 문제에 대해 Vite 가 어떤 전략을 취하고 있는지 살펴보겠습니다.

Bundler

ESM이 브라우저에서 이용 가능하기 전에는 native 방식의 모듈 관리 매커니즘이 존재하지 않았습니다. 그리고 이 문제를 해결하기 위해 번들러가 등장했습니다. 번들러는 소스 코드를 합치고 여러 처리과정을 거친 후에 브라우저에서 동작할 수 있는 파일을 만들어 냅니다.

만약 앱의 규모가 커진다면 번들러의 크기도 점점 커질 것이고 처리 과정도 시간이 오래걸릴 것입니다. 이 문제를 해결하기 위해서 Code Splitting과 같은 전략을 사용하기도 합니다.

Vite의 특징

Vite는 dependencies 와 source code 로 카테고리를 나누어서 개발 서버의 cold start 시간을 단축시킵니다.

Dependencies

dependencies 는 대부분 개발하는 동안 변화가 거의 없는 의존성 모듈들 입니다. ESM 은 bare module imports 를 지원하지 않기 때문에 아래와 같은 코드를 만나면 에러를 뿜을 것입니다.

// bare bomdule imports는 아무 경로 표시가 되지 않은 것을 의미한다. 
import {someMethod} from 'my-dep';

vite는 이러한 bare module imports 를 소스 코드 전체에서 찾아내고 COMMONJS/UMD 모듈들을 ESM으로 변환하고 번들링을 진행합니다. 이러한 사전 번들링 작업은 esbuild를 통해 이루어지며 vite의 cold start 속도를 빠르게 만들어 줍니다. 번들링이 완료되면 imports 문을 node_modules/.vite/my-dep.js?v-ffsf2dfw 와 같이 유효한 경로로 다시 적어줌으로써 브라우저가 정확하게 import 할 수 있도록 해줍니다.

esbuild는 golang으로 작성된 번들러로써 기존 자바스크립트 기반 번들러보다 최소 10배 이상 빠르다고 합니다.

Source code

source code 는 우리가 작성 중인 코드로써 변화가 잦습니다.그러나 모든 코드가 동시에 로드될 필요는 없습니다. Vite는 브라우저의 요청에 따라 필요한 소스코드를 변환해서 제공하면 됩니다. 이는 작업의 책임을 브라우저와 나눈다고도 볼 수 있습니다.

Production

Vite의 이러한 방식에도 불구하고 배포를 위해서는 기존 번들 과정이 필요합니다. 아직 ESM을 프로덕션에 배포하는 것은 비효율적인 부분이 있기 때문인데, 중첩된 import 문 등으로 인해 네트워크의 Round trip이 증가하기 때문입니다. 따라서 기존 번들링 기법을 최대한 활용하는 것이 최선이며 Vite에서는 이를 위한 빌드 명령어들을 제공하고 있습니다. 빌드 프로세스는 내부적으로 Rollup을 사용하고 있으므로 원하는 경우 직접 Rollup plugin들을 설정해줄 수도 있습니다.

// vite.config.js
module.exports = defineConfig({
  build: {
    rollupOptions: {
      // https://rollupjs.org/guide/en/#big-list-of-options
    }
  }
})

P.S

Vite는 ESM을 사용하기 때문에 package.json 에서 type: "module" 필드가 있습니다. 만약 기존 commonJS 방식의 파일을 그대로 사용하고 싶다면 끝에 cjs 라고 명시해주어야 합니다.