vite와 turbopack

Next로 만든 프로젝트는 시간이 지나면서 코드 변경 후 저장하면 5초가 지나고  반영되는 걸 종종 경험했다.

 

Next는 turbopack기반이고 이 부분에 대해 알아보았다.

 

번들링

브라우저가 이해하는건 3개다.

- html

- css

- js

 

그런데 우리가 쓰는건 React, TS, CSS module, import, .env, ....

 

브라우저는 이걸 하나도 못읽는다. 그래서 중간에 변환해주는 도구가 필요한데 이게 바벨과 번들러다.

 

tsx -> jsx -> js 로 변환하는 과정을 바벨이 처리하고 이 js를 하나로 묶어주는 기능을 번들러 webpack이 처리했다.

 

그런데 go, rust등으로 컴파일러를 만들게 되면서 babel보다 30배 이상 빠른 도구들이 만들어졌고 바벨을 쓸 필요가 없어졌다.

 

예를들어 Turbopack은 Rust기반의 SWC 기반이라 babel이 필요없다.

 

어쨌든 그래서 tsx -> jsx -> js -> bundle.js 의 과정을 하는 무언가가 필요한데 이게 트랜스파일러(babel)와 번들러(webpack)의 역할이었고 

 

Turbopack은 이 번들링을 엄청 빠르게 해주는 도구다.

Turbopack

webpack 과 같은 역할을 하는 번들러다. Rust로 만들어져서 번들링을 엄청 빠르게 한다. 그리고 next에 최적화되어 있다.

 

문제는 번들링은 전체 코드를 묶어주는거라 결국 전체를 읽게되고 프로젝트가 비대해질수록 개발환경 구동이 오래 걸리게 된다.

(참고: https://news.hada.io/topic?id=7711)

 

또한 번들링된 파일들은 dist같은 파일에 저장되고 서빙된다.
(이 때문에 next에서 build 후 pnpm run dev하면 에러나서 .next지워야 하는 상황 발생하는데 이유는 .next를 캐시로 쓰는 개발모드와 빌드 결과물을 .next에 저장하는 두 기능의 충돌때문이다.)

 

한편 브라우저 네이티브 기능을 그대로 사용하는 도구가 있는데 그것이 vite다.

 

Vite

ES6에서는 브라우저가 import를 이해할 수 있으니, 필요한 파일만 변환해서 주면 번들링을 할 필요 없지 않나? 라는 관점에서 만들어진 도구다.

 

tsx -> js 과정은 바벨보다 빠른 go로 만들어진 esbuild가 실행한다.

 

그 후 import를 타고 메모리에서 처리되어 바로 필요한것만 빠르게 서빙한다. 

 

이 때문에 전체 번들링하는 webpack보다 빠르고 프로젝트가 커질수록 turbopack과의 차이도 벌어지는 것이다.

(vite도 production에선 번들링한다)