차세대 모듈 번들러

2023. 8. 13. 23:27카테고리 없음

기존 번들러의 어떤 점이 문제였을까?

기존의 번들러들 (Webpack, Parcel, Rollup, … )들은 기존 모듈 시스템들의 문제점을 해결해주었지만, 이제는 속도가 문제가 되었다.

 

Vite의 공식문서에서는 이런 차세대 번들러가 어떤 문제를 해결하는지 명확히 알려주고 있다.

 

“하지만 애플리케이션이 점점 더 발전함에 따라 처리해야 하는 JavaScript 모듈의 개수도 극적으로 증가하고 있습니다. 심지어 수천 개의 모듈이 존재하는 것도 대규모 프로젝트에서는 그리 드문 일이 아닙니다. 이러한 상황에서 JavaScript 기반의 도구는 성능 병목 현상이 발생되었고, 종종 개발 서버를 가동하는 데 비합리적으로 오랜 시간을 기다려야 한다거나 HMR을 사용하더라도 변경된 파일이 적용될 때 까지 수 초 이상 소요되곤 했습니다. 이와 같은 느린 피드백 루프는 개발자의 생산성과 행복에 적지 않은 영향을 줄 수 있습니다. ”

 

또한 기존의 자바스크립트 개발 도구들에서 느끼는 피로감도 문제였다. (https://hackernoon.com/how-it-feels-to-learn-javascript-in-2016-d3a717dd577f)

한 줄의 자바스크립트 코드를 작성하기 전에 200메가바이트의 dependencies들을 다운로드 해야하는 문제가 있었다.

차세대 번들러들은 새로운 스펙 ESM에 의해 활성화되었다. 현재 모든 메이저 브라우저는 ESM을 지원한다.

게임체인저 esbuild

esbuild는 Evan Wallace(피그마 CTO)에 의해 만들어졌다. 기존의 번들러보다 10-100배 빠른 빌드 속도를 보인다고 한다.

 

어떻게 이만큼의 성능 향상이 가능했을까?

이전의 번들러들은 JS기반의 오픈소스였다. 반면 esbuild는 GO언어로 작성되었다. esbuild의 공식문서에서 esbuild가 Go를 사용함으로써 어떻게 성능향상을 이루었는지 찾을 수 있다.

 

 

“대부분의 다른 번들러는 JavaScript로 작성되었지만, JIT 컴파일 언어는 CLI 어플리케이션에서 최악의 성능을 보이는 상황입니다.

또한 Go는 코어부터 병렬 처리를 위해 설계된 반면 JavaScript는 그렇지 않습니다.”

 

하지만 아직 esbuild를 사용하기 어려운 부분이 있다.

 

esbuild는 1.0버전을 내놓지 않았다. 사이드 프로젝트에서 번들링 속도를 높이기 위해 충분히 사용 가능하지만 커다란 실제 프로덕션에서는 아직 이른 감이 있다.

 

또한 웹팩과 같은 기존의 번들러들은 단순한 빌드 도구라기보다는 DevServer, 각종 Loader를 통한 트랜스 파일, 코드 스플리팅, 트리쉐이킹, HMR, CSS, HTML, asset 지원 등의 기능을 갖춘 통합 툴이다. 하지만 esbuild는 단순한 빌드 도구일 뿐이다.

 

그리고 아주 미미한 차이지만 minify와 bundle을 사용해도 Rollup/terser 파이프라인만큼 작은 번들이 생성되지 않는다. esbuild는 가능한 적은 코드를 훑기 때문에 번들 사이즈를 희생한다. 하지만 매우 작은 차이이고 번들링 속도에 더 높은 가치가 있는 경우가 있을 것이다.

Snowpack

Snowpack은 Skypack과 Pika의 제작자들이 만든 툴이다. 훌륭한 개발 서버를 제공하며 “번들하지 않는 개발” 철학으로 만들어졌다.

 

이 역시 Snowpack의 공식문서에 잘 나와있다.

 

“번들하지 않는 개발은 개발 중에 개별 파일을 브라우저로 전송하는 개념입니다. 자주 사용하는 도구(바벨, 타입스크립트, Sass)로 파일을 빌드한 다음 ESM import와 export를 활용해 브라우저에서 개별적으로 로드할 수 있습니다. 파일을 변경할 때마다 Snowpack은 해당 파일만 다시 빌드합니다.

번들하지 않는 개발은 기존의 번들 개발 방식에 비해 몇 가지 장점이 있습니다:

  • 단일 파일 빌드가 빠릅니다.
  • 단일 파일 빌드는 deterministic 합니다
  • 단일 파일 빌드는 디버깅하기가 더 쉽습니다.
  • 프로젝트 크기는 개발 속도에 영향을 미치지 않습니다.
  • 개별 파일이 더 잘 캐시됩니다.

마지막 점이 핵심입니다: 모든 파일은 개별적으로 빌드되고 무기한 캐시됩니다. 개발 환경은 파일을 두 번 이상 빌드하지 않으며 브라우저는 파일을 두 번 다운로드하지 않습니다(파일이 변경되기 전까지는). 이것이 바로 번들하지 않는 개발의 진정한 힘입니다.”

 

Snowpack은 esbuild를 감싸는 훌륭한 래퍼라고 할 수 있다.

 

하지만 역시나 Snowpack을 사용하기 어려운 부분이 있다.

22년 4월 부로 더 이상 유지 관리 되지 않으며 새 프로젝트에는 권장되지 않는다고 공식문서는 말하고 있다.

 

또한 Snowpack의 대안으로 유지관리가 잘되는Vite를 추천하고 있다.

Vite

Vite는 Vue제작자 Evan You가 개발했다. esbuild가 빌드 단계에 집중하고 Snowpack이 개발 서버에 집중하는 반면, Vite는 개발 서버와 Rollup을 사용한 최적화된 빌드 명령을 모두 제공한다.

 

Vite는 esbuild와 ESM을 이용한 개발모드, 개발 서버, 프록시 서버, 번들툴, 코드 스플리팅, HMR 등 지금까지 나왔던 Snowpack의 컨셉과 다른 번들 도구에서 제공하는 기능을 하나로 모은 프론트엔드 번들 도구이다.

 

Vite의 개발 서버는 특히 강력하다. Vite는 esbuild를 통해 프로젝트의 모든 dependencies들을 하나의 ESM으로 미리 번들링한 다음, 이를 매우 강력하게 캐시된 HTTP 헤더와 함께 제공한다.

 

Production 빌드에서 Vite는 여러 가지 최적화가 포함된 사전 구성된 프로덕션 빌드에 롤업을 사용한다. 의도적으로 zero-config 빌드를 제공하므로 대부분의 사용 사례에 충분하다. 이 빌드에는 번들링, minification 그리고 트리쉐이킹과 같은 롤업 기능이 포함되어 있다.

 

 

https://yozm.wishket.com/magazine/@teo_yu/

https://css-tricks.com/comparing-the-new-generation-of-build-tools/#h-vite

https://www.snowpack.dev/concepts/how-snowpack-works#unbundled-development

https://ko.vitejs.dev/guide/why.html

https://esbuild.github.io/faq/