Rollup을 활용한 번들링 최적화 (Import cost 줄이기) - 1편

이슈를 발견하고 해결하는 삽질,, 아 아니 과정을 포스팅 하겠습니다

👿  이슈

MUI(Material-UI) 기반으로 개발된 부서 공통 컴포넌트 라이브러리에서 하나의 컴포넌트를 가져올 때 해당 모듈의 사이즈가 MUI의 컴포넌트 사이즈에 비해 크게 측정되는 것을 발견했습니다. 또한 Button과 ButtonGroup 등 다른 컴포넌트임에도 동일한 사이즈로 측정되는 현상을 확인했습니다.

 

🙄  원인 파악 과정

 

1.  부서 공통 컴포넌트 라이브러리 코드 분석하기

 

 

 

 

부서 공통 UI 컴포넌트는 rollup을 통해 번들링 되고 있으며 cjs(Common JS)와 esm(ES Modules)포맷 모두 지원하고 있었습니다. 리액트 프로젝트에서 import/export 문으로 모듈을 불러오고 내보내고 있으므로, esm 포맷으로 번들링 되는 과정에 포커스를 두고 문제를 해결해 보기로 했습니다.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

2. MUI based library 살펴보기

 

원인을 파악하기 위해,
npmjs.com에서 부서 공통 UI 라이브러리와 비슷한 환경인

MUI based 라이브러리를 찾아서 살펴봤습니다.

 

 

저희와 비슷한 환경에서 만들어진 UI 라이브러리 중에서 해당 이슈가 발생되지 않는 라이브러리 코드를 분석할 생각이었는데,
직접 라이브러리 몇 가지를 install 해서 확인한 결과 사내 공통 UI 라이브러리와 동일한 이슈가 발생했습니다.

→ 원인 파악 실패 ..

 

3. MUI 코드 살펴보기

그래서 직접 MUI의 코드를 살펴봤습니다. 링크

@mui/material도 저희와 동일하게 rollup을 활용하여 번들링을 하고 있었고,
MUI의 rollup.config.js 파일과 저희의 rollup.config.js 파일 간에 유사한 코드가 많은 걸로 보아
이미 MUI의 번들링 과정을 참고하여 만들어진 것임을 확인했습니다.

다른 점이 있다면 umd 포맷으로 번들링 되고 있다는 점인데,
cjs/esm/umd 포맷에 대해 검색해 본 결과 해당 이슈는 별개의 문제일 것이란 판단을 했습니다.
(참고 : cjs/esm/umd 설명)

→ 원인 파악 실패

 

4. node-modules 살펴보기

다음 스텝으로 리액트 프로젝트에서 각 패키지의 구조를 살펴보았습니다.
왼쪽은 부서 공통 UI 컴포넌트, 오른쪽은 팀 공통 UI 컴포넌트 라이브러리의 구조입니다.

동일한 이슈가 있는 두 라이브러리의 구조를 확인해보니
모두 esm 포맷의 번들링 결과물이 하나의 index.js 파일로 관리되고 있었습니다.

 

 

 

 

반면 해당 이슈가 없는 MUI는 번들링 결과물이 컴포넌트 별로 관리되고 있는것을 확인했습니다.

여기서 힌트를 얻어 번들링 과정에서 컴포넌트 별로 분리하면 MUI와 동일하게 동작할것이라 생각했습니다.

 

 

 

 

→ 원인 파악 성공 ,, ? 🤔🤔

 

원인 파악은 여기까지 하고,
해결 과정은 다음 편에서 다시 작성해보겠습니다