default export를 피해야 하는 이유?

우아한테크코스 크루인 도비의 블로그를 보다가,

기억해두면 좋겠다 싶은 내용이 있어 원문을 읽어본 후 짧게 정리한 글.

 

ES Modules의 default exports는 기존에 존재하던 'CommonJS 모듈 시스템'과의 호환을 위한 타협.

기존의 CommonJS 모듈은 다음과 같은 형태를 띠고 있기 때문이다. (객체로 export하는 형식)

호환성을 위해 지원되는 문법일 뿐, 여러모로 비효율적인 부분들이 많다고 한다.

module.exports = function() {...}

 

1. default exports는 import하는 곳에 따라 자유자재로 이름을 붙여줄 수 있기 때문에,

같은 모듈이더라도 사용처에 따라 이름이 달라질 수 있다.

이는 곧 큰 단위의 리팩토링을 어렵게 만드는 요인이 된다.

반면, named exports는 모든 사용처에서 동일한 이름을 사용한다.

 

2. named exports는 export 되는 값들에 이름을 부여하기 때문에,

IDE가 이를 찾아서 자동으로 import를 도와줄 수 있다. (생산성 향상)

 

3. 가끔 하나의 거대한 객체를 default export하는 경우가 있는데, 이는 tree-shaking을 불가능하게 만든다.

named exports로 값을 하나씩 export 해주면, 사용하지 않는 값들은 tree-shaking함으로써 번들 사이즈를 줄일 수 있다.

// do not try this at home
export default {
  propertyA: "A",
  propertyB: "B",
}

// do this instead
export const propertyA = "A";
export const propertyB = "B";

 

+ 도비의 글에 따르면, 모듈 자체가 ES Modules로 작성된 경우가 아니면 아예 tree-shaking이 안된다고 함.

(별도의 plugin을 설치하면 가능하다고 한다)

 

+ default export도 webpack의 sideEffect: false 옵션을 통해 tree-shaking을 해줄 수 있긴 하다.

※ sideEffect: 사용하진 않지만 번들에 포함되는 코드들.

직접적으로 사용하진 않지만 다른 코드에 영향을 끼칠 수 있다고 판단되면 'sideEffect가 발생했다'고 한다.

이를 false로 표시해준다는 건, package와 dependency들이 sideEffect를 일으키지 않는다고 알려주는 것.

 

 

 

출처

도비의 블로그 - default export와 named export의 차이점: https://zereight.tistory.com/1134

TOAST UI - 트리쉐이킹으로 자바스크립트 페이로드 줄이기: https://ui.toast.com/weekly-pick/ko_20180716

Naver FE Platform Medium - Webpack에서 Tree Shaking 적용하기: https://medium.com/naver-fe-platform/webpack%EC%97%90%EC%84%9C-tree-shaking-%EC%A0%81%EC%9A%A9%ED%95%98%EA%B8%B0-1748e0e0c365

Neufund Medium - Why we have banned default exports in Javascript and you should do the same: https://blog.neufund.org/why-we-have-banned-default-exports-and-you-should-do-the-same-d51fdc2cf2ad