SLASH 21 - JavaScript Bundle Diet

같은 라이브러리인데 버전이 다른 것이 중복으로 들어가는 현상을 다룬다. 원인은 패키지 매니저의 특성으로, 여러 라이브러리가 같은 라이브러리의 서로 다른 버전을 참조하는 상황을 nested dependencies라 한다. npm은 트리 구조로 필요한 버전을 모두 받아 한 라이브러리 아래 또 node_modules를 만들어 저장하고, webpack도 같은 방식으로 번들링하므로 서로 다른 두 버전이 모두 번들에 들어갈 수 있다. 중복이 쌓이면 번들과 node_modules가 커진다. npm은 semver를 가정해 메이저가 같으면 더 높은 버전 하나로 통합하고, 안 되면 npm dedupe로 줄일 수 있다. yarn을 쓰는 토스에서도 querystring이 중복된 사례가 있었고, 이럴 때는 yarn-deduplicate 같은 도구로 통일하길 권한다.

또 다른 중복 사례가 lodash다. 직접 쓰지 않아도 서드파티 때문에 포함되는 경우가 많고, ESM 버전 lodash-es, CJS 버전 lodash, 기능별 단독 패키지가 있어 같은 기능이 여러 형태로 중복될 수 있다. 이때 webpack의 alias로 한 구현으로 모으면 중복을 피한다. 중복을 피했다면 꼭 필요한 코드만 쓰도록 다듬어야 하는데, lodash처럼 트리 셰이킹을 지원하지 않는 것은 babel-plugin-lodash로 실제 쓰는 부분만 가려낸다. groupBy처럼 기능 대비 용량이 큰 함수는 가능하면 네이티브 함수를 쓰거나 더 가벼운 함수를 직접 구현해 쓴다. 더 가벼운 라이브러리를 찾을 때 주의할 점은 폴리필이다. webpack은 브라우저·노드 환경을 맞추려 폴리필을 추가하는데, 라이브러리 자체는 작아도 폴리필이 과도하게 붙으면 더 무거워질 수 있다. node-rsa는 노드 환경만 생각하고 만들어진 탓에 crypto·Buffer·Number 폴리필이 붙어 폴리필 영역만 100KB 넘게 추가된 사례가 있었다. 명시적으로 끄거나 브라우저 환경을 잘 판단하는 라이브러리를 쓰라고 권한다.

라이브러리를 잘 고르고 비교하기 위해 Bundle Phobia를 소개한다. gzip 압축 시 용량, 다운로드 시간, 버전별 용량을 보여주고 의존성도 미리 확인할 수 있는 사이트로, 쓰려는 라이브러리가 좀 크더라도 이미 쓰는 것과 의존성이 많이 겹치면 실제 용량 변화는 미미할 수 있어 그런 판단에 유용하다. 비슷한 기능의 라이브러리끼리 용량 비교나 트리 셰이킹 시 함수별 용량 예측도 가능하다.

이어 라이브러리를 만드는 관점으로 트리 셰이킹을 깊게 다룬다. 트리 셰이킹은 정적 분석으로 사용하지 않는 코드를 제거하는 기술인데, 사이드 이펙트가 없을 때만 안전하게 동작한다. webpack은 package.json의 sideEffects 필드를 참고하며, 라이브러리 제작 시 ESM(module) 옵션을 켜면 원본과 유사한 구조의 파일이 나와 일부 파일만 트리 셰이킹에 실패하도록 완화할 수 있다. 컴파일 툴도 중요해서, terser가 코드를 지울 때 도움을 주는 PURE 어노테이션을 babel은 붙여 주지만 타입스크립트 컴파일러는 아직 붙여 주지 않으므로 가급적 babel로 컴파일하라고 권한다. 마지막으로 청크를 framework·commons·shared·page 단위로 나누고 dynamic import와 prefetch를 활용해 큰 라이브러리의 영향을 최소화한 결과, 토스는 번들을 최대 3분의 1까지 줄이고 초기 로딩 속도를 절반 가까이 단축했다고 마무리한다.