CommonJS vs ES Modules

배경

함수들끼리 데이터를 공유하고 싶다면 어떻게 해야할까? 전역 스코프에 해당 데이터를 둔다면 다른 내부 요소에 의해 망가질 수도 있고, 순서가 뒤엉켜 전역 스코프의 요소가 존재하지 않을 수도 있다.

따라서 모듈이라는 방식을 이용하면 각각 필요한 모듈을 import하여 사용함으로써 어디에서 에러가 나는지 파악하기 쉽다. 모듈을 만들고 import, export 하는 시스템을 모듈 시스템이라 하는데 현재 2가지의 모듈 시스템이 활발하게 사용되고 있다.

• CommonJS
• ES modules

 

---

차이점

기초 문법

CommonJS

const module = require('어쩌구');
const { func } = require('어쩌구');

module.exports = '어쩌구'; // default exports
module.exports.func = () => {}; // named exports

 

ES Modules

import a from '어쩌구';
import {func} from '어쩌구';

export const a = '어쩌구'; // default exports
export default func = () => {}; // named exports

 

호환

ESM와 CJS는 호환이 안된다. ESM에서 CJS를 default import하거나 CJS에서 ESM을 require로 가져오는 방법만이 가능하지만 이조차도 많은 boilerplate와 번들러가 필요하며 순서가 보장되지 않는다.

 

 

비교

<ES Modules>

• 모듈을 비동기 환경에서 다운로드하며, import export 구문을 찾아서 파싱한다.
• 따라서 ES modules는 실행해보지 않아도 import, export 에러를 감지할 수 있다.
• config를 type="module" 로 set 해주어야 사용할 수 있다.
• top-level await가 가능하다.

 

<Common JS>

• require가 동기로 이루어지므로 promise를 return 하지 않는다.
• 따라서 CommonJS는 실행해보아야 import, export 에러를 감지할 수 있다.
• 기본 값이다.
• top-level await가 불가능하다.

 

동작 방식

ES Modules

개발자가 지정한 파일을 entry point로 하여 나머지 파일들은 import문을 따라가며 찾는다. 파일을 브라우저에서 사용하려면 모듈 레코드 라는 과정이 필요하고 이후 모듈 레코드를 모듈 인스턴스로 변환해야한다. 모듈 인스턴스는 코드와 현재 상태를 결합하는 역할을 한다.

모듈을 불러오는 과정은 entry 파일이 모듈 인스턴스 전체 그래프를 그리면서 진행되는데, ES 모듈 명세에 따르면 그 과정은 크게 구성, 인스턴스 화, 평가로 이루어진다.

이렇게 ES modules는 비동기방식으로 단계가 진행되는 듯 보이지만 ES 모듈 명세 말고도 loader가 파일을 불러오는 방식에 따라서도 영향을 받기 때문에, 사용 중인 플랫폼에 따라 다른 로더가 동기적으로 파일을 로드할 수도 있다.

 

1. 구성 : 모든 파일을 확인하고(resolution) 다운로드하고 모듈 레코드로 구문분석한다.

 

loader는 파일을 찾아서 다운로드하는데, script 태그의 src를 통해 entry point를 찾고 import, export를 거쳐가면서 파일들을 찾는다. 미리 전체 모듈 그래프를 작성해야하며 이 때 변수에는 아직 값이 없다. 따라서 기본적으로는 모듈 경로에 변수 값을 넣어 사용할 수 없지만, import 표현식 을 사용하면 dynamic import가 가능하므로 변수 값을 사용할 수 있다.

모듈 레코드로 분석하면 브라우저가 모듈의 다른 부분을 이해할 수 있고, 해당 레코드는 모듈맵에 추가되어 필요할 때마다 로더가 가져올 수 있다. 모듈 분석 전에 해당 파일이 모듈임을 알려주기 위해 스크립트 태그 내부에 type="module"을 표시해주어야 한다. node 환경에서는 .mjs 확장자로 모듈임을 알려준다.

 

2. 인스턴스 화 : export된 값을 위해 메모리의 공간을 찾고 export, import를 해당 공간에 linking한다.

 

모듈 레코드로부터 모듈 환경 레코드를 생성하여 변수를 관리한다. 변수 값은 평가가 끝난 후에 채워진다.

위와 같이 export와 import를 같은 변수에 linking한다. export 듈은 변수를 수정할 수 있지만, import는 불가능하다.

 

3. 평가 : 코드를 실행하여 변수의 실제 값으로 채운다.

 

할당된 변수 값을 채운다. 이 때 다른 작업이 일어났다고 해서 모듈이 2번 평가되면 안되므로 모듈 맵을 이용하여 하나의 모듈 레코드만이 존재하도록 보장한다.

 

 

Common JS

• 파일을 import 순서에 따라 순차적으로 완전 실행하므로 변수 값을 할당할 수 있다.
• 변수에 linking 시 export 값을 사본으로 복사하여 사용한다. 따라서 export, import하는 변수가 다르다.

 

순환 의존성

// main.js
let count = require('./counter.js').count;
export message = 'hi';

// counter.js
let message = require('./main.js').message; // message 정의되어 있지 않음
setTimeout(() => console.log(message), 0); // CommonJS : undefined, ES Modules : 'hi'

순환관계가 있을 때 CommonJS는 변수 값을 복사해서 사용하므로 main.js에서의 message가 할당이 되어도 counter.js에서의 변수는 변하지 않는다. 하지만 ES Modules에서는 같은 변수를 참조하고 있으므로 setTimout에서 제대로 할당된 변수가 출력된다. ES Module은 위와 같이 순환 의존성을 지원한다.

 

---

실제 사용

React에서는 ESModules을 주로 사용한다. 패키지 모듈들은 결국 CommonJS를 기본 모듈 시스템으로 선택하기 때문에, 코드 작성 시 CommonJS로 변환해주어야 하는데 해당 작업은 번들러인 Babel이 수행한다.

https://runebook.dev/ko/docs/babel/babel-plugin-transform-modules-commonjs/index

Babel - @babel/plugin-transform-modules-commonjs - History 참고 : 이 플러그인은 modules 옵션 아래 @babel/preset-env

 

---

 

정리

대표적인 두 가지의 모듈 시스템 중 CommonJS가 처음에 등장하였으나, 현재는 ES modules 모듈 시스템이 많이 사용되고 있다. CommonJS와 비교하여 ES modules는 비동기로 동작하여 속도가 빠르고 실제 사용되는 부분만을 import(tree shaking) 하여 메모리를 적게 차지하며, 가독성이 좋고 순환 의존성을 지원한다는 이점이 있다.

 

---

 

참고

https://yceffort.kr/2020/08/commonjs-esmodules
https://ui.toast.com/weekly-pick/ko_20180402
https://ko.javascript.info/modules-dynamic-imports
https://www.daleseo.com/js-module-import/

 

 

 

 부정확한 정보가 담겨있을 수 있습니다! 

 댓글로 알려주세요 :)