webpack과 tree shaking (named export VS default export)
우테코 Lotto 미션을 진행하면서 named export
와 default export
에 대한 의문이 생겼습니다.
어떤 기준으로 때에 맞게 named/default export
를 써야하는지 궁금해, 리뷰어에게 이것에 대해 학습할 수 있는 키워드를 요청했습니다.
리뷰어가 제시한 키워드는 ‘tree shaking’, ‘webpack 번들’ ‘번들 사이즈가 커졌을 때 성능에 끼치는 영향’ 이었습니다.
우선 tree shaking을 알아보기 전에 webpack 번들과 번들 사이즈가 커졌을 때 성능에 끼치는 영향에 대해 알아보는게 좋다고 하여 두 개를 먼저 알아보겠습니다.
webpack
모던 Javascript 애플리케이션을 위한 정적 모듈 번들러 webpack이 애플리케이션을 처리할 때, 내부적으로는 프로젝트에 필요한 모든 모듈을 매핑하고 하나 이상의 번들을 생성하는 디펜던시 그래프를 만든다.
설명에 나와있는 디펜던시 그래프가 무엇인지 궁금해서 함께 찾아봤습니다.
디펜던시 그래프: 하나의 파일이 다른 파일에 의존할 때마다, webpack은 이것을 의존성으로 취급한다. 이를 통해 webpack은 이미지 또는 웹 폰트와 같은 코드가 아닌 에셋을 가져와 애플리케이션에 의존성으로 제공할 수 있다. 엔트리 포인트에서 시작하여 디펜던시 그래프를 재귀적으로 빌드한 다음, 모든 모듈을 브라우저에 의해 로드되는 작은 수의 번들로 묶는다.
즉, webpack의 역할은 웹 애플리케이션을 구성하는 자원( HTML, CSS, Javascript Images …)들을 각각 모듈화하고 이를 통합하여 하나의 번들로 만드는 역할을 합니다.
그렇다면 번들의 사이즈가 커진다면 어떤 일이 발생할까요
사이즈가 커질수록 초기 컴파일과 실행 속도가 늦춰질 것입니다. 그렇게 자연스럽게 사용자 경험에도 좋지 않은 영향을 끼치게 될 것입니다.
프론트엔드 개발자는 사용자 친화적인 소프트웨어를 만들어야 합니다. 당연히 이런 문제점은 해결해야 합니다.
webpack은 이런 문제점을 해결할 수 있는 기능으로 tree shaking을 제공합니다.
Tree Shaking
사용하지 않는 코드를 DOM트리로부터 제거하여 파일의 크기를 줄이는 기능이다.(webpack4 부터 제공) 번들링하는 모드를 두 가지 제공한다. 하나는 개발 단계에서 사용하는 development, 나머지 하나는 배포 단계에서 사용하는 production.
tree shaking은 production 모드로 실제 배포를 위해 번들링 할 때만 적용된다.
utils.js
라는 파일로 예시를 들어보겠습니다.
해당 파일은 유틸 메서드들을 보유하고 있는 모듈이고 코드 라인 수는 1300줄이라고 가정해보겠습니다.
// in utils file
function foo() {
console.log('Hello');
}
function bar() {
console.log('World');
}
...
그리고 여기서 필요한 메서드는 단지 foo
메서드 뿐이라고 가정하겠습니다.
function App() {
foo();
}
이 상황에서 utils
의 foo
메서드를 사용하기 위해 어떤 방식으로 export
하는게 파일 최적화 측면에서 더 도움이 될까요?
아무래도 export { foo }
처럼 named export
를 하는게 최적화하는데에 도움이 되겠죠.
export default utils
는 쓸데없는 메서드들까지 함께 넘겨주게 됩니다. 지금은 파일 하나라서 큰 차이가 없어 보일지도 모르지만, 큰 프로젝트에서 많은 파일들이 위와 같은 상황이라면 큰 차이가 날지도 모릅니다.
tree shaking은 named export
한 파일들을 최적화해줍니다. 가지치기 하듯이 사용하지 않는 코드들을 DOM트리로부터 제거하여 파일의 크기를 줄여줍니다.
그러나 아무때나 tree shaking을 사용할 수 있는 것은 아닙니다. 다음과 같은 세 가지 조건이 충족되어야 합니다.
named export
를 사용해야 tree shaking이 가능합니다.- ES Modules를 사용해야 합니다.
- Babel이 js파일을 트랜스파일링 하는 과정에서 ES Modules를 CommonJS로 변환하는지 확인해야 합니다.
- side effect가 발생하는지 체크해야 합니다.
- 사이드 이펙트가 발생하는 경우 webpack에서 필요없는 파일 여부를 파악할 수 없기 때문에 tree shaking을 수행하지 않습니다.
이번 게시글을 준비하면서 개발 환경 개선은 물론, 사용자 경험을 개선하려는 개발자들의 노력을 느낄 수 있었습니다. 개발은 혼자하는 것이 아닌 함께하는 것이고, 소프트웨어는 사용자에게 좋은 경험을 제공하려 항상 노력해야한다는 것을 다시 한 번 깨달았습니다.