모듈 시스템

썸네일

🗣️ import과 require의 차이를 알고 계시나요? 

 

🤔 노드 프로젝트에서는 require 많이 본 거 같고, react에서  import 많이 썼던 거 같은데? 

import과 require에 대해 알기 위해서는 모듈 시스템이라는 것에 대해 알아야 한다.

오늘은 모듈 시스템이 무엇이고, 어떤 것들이 있으며, 각각의 특징과 장단점을 살펴보자.

JS 모듈 시스템이란?

예전 웹에서 자바스크립트가 담당하고 제공할 수 있는 기능들은 페이지를 보여주는 것 정도였다.

하지만 점차 자바스크립트의 역할이 거대해지고, 기능들을 만들면서 네임스페이스며 dependency며 관리할 것도 비례(정비례는 아닐 수도?)해서 방대해졌다.

모듈 시스템은 이렇게 관리하기 어려운 스코프 이슈를 해결하기 위한 방안으로 등장하게 되었다.

모듈러 js가 아닌 코드(왼쪽)와 모듈러 js 인 코드

JS 모듈 시스템을 알아야 하는 이유

프로젝트를 하다 보면 프로젝트를 넘나들며 공통으로 사용하는 기능들을 복사+붙여놓기 반복작업을 하는 경우가 종종 있다.

근데 한 곳의 코드가 변경되면 수작업으로 프로젝트들 모두에서 sync를 맞추는 작업을 해야 하는 수고스러움이 있다.

 

이 작업에 지쳐서 다른 프로젝트에서도 손쉽게 공통 기능들을 가져다 쓸 수 있고, 변경 사항도 일괄+자동 적용하고 싶다는 생각이 든다면, 라이브러리로 만들어서 dependency로 재사용해보는 방법이 있다. 

 

라이브러리를 딱! 만들고 이제 마지막 퍼블리싱 단계에서 고민들이 생겨난다.

 

1. tree shaking이 가능하도록 하는 방법?

2. JS 모듈 시스템 중에서 뭘 써야 하지?

 

이때 JS모듈 시스템에 대해 알고 있다면, 이 고민들에 대한 답을 찾을 수 있다.

JS 모듈 시스템의 종류

CommonJS	AMD: Async Module Definition	UMD: Universal Module Definition	ECMAScript Module (ESM)
require 와 module.exports	require	require와 module.exports	import와 export
- ES5 모듈 시스템  - node로 구현 - 모듈 설치 시 서버사이드에 쓰임 - import를 하면 object를 반환받는다   따라서 다음과 같은 특징이 있다:       -  tree shaking이 불가능     - 프로퍼티 검색(property lookup)이 런타임에 진행되므로 정적분석(static analyzing)이 불가능 - 항상 object의 복사본을 받으므로 모듈 자체의 즉각적인 변화는 반영되지 않는다 - 순환 (cyclic) dependency 관리가 어렵다 - syntax가 간단하다	- ES5 모듈 시스템  - RequireJs로 구현 - 모듈을 동적으로 로드하고 싶을 때 클라이언트 (브라우저)에서 쓰임 - syntax가 복잡하다	- ES5 모듈 시스템  - AMD와 CMJ 환경 모두에서 사용 가능 - CommonJS의 syntax와 AMD의 비동기 로딩 - UMD는 기본적으로 두 환경에서 모두 사용 가능하도록 하면서도 전역 변수 선언도 지원한다 - 따라서 UMD 모듈은 클라이언트와 서버 모두에서 사용 가능하다	- ES6 모듈 시스템  - 클라이언트와 서버 모두에서 사용 가능 - 런타임/ 정적(static) 모듈 로딩 지원 - import를 하면 binding value (실제 값)을 반환받는다    - 따라서 모듈 자체의 즉각적인 변화가 반영된다 - 정적 분석 (static analyzing) 가능 : import/export를 컴파일 도중에 정적으로 할 수 있다   -  정적분석이 가능하므로 Tree shaking이 가능하다 (ES6지원) - CJS에 비해 순환 dependency 관리가 용이하다

 

🌴 tree shaking이란?
자바스크립트의 관점에서는 tree shaking이란 죽은 코드 제거를 가리키기 위해 사용되는 용어이다.

ESM 특징 살펴보기 (ft. CJS와 비교)

ESM export 방식 두 가지 : Named exports와 default exports

 

ESM export 방식에는 Named exports (모듈 당 여러개)와 default exports (모듈 당 하나)가 있다.

동시에 둘을 사용하는 것은 가능하나, 되도록이면 분리해 주는 것이 좋다.

 

Named exports 사용

//------ lib.js ------
export const sqrt = Math.sqrt;
export function square(x) {
    return x * x;
}
export function diag(x, y) {
    return sqrt(square(x) + square(y));
}

//------ main.js ------
import { square, diag } from 'lib';
console.log(square(11)); // 121
console.log(diag(4, 3)); // 5

// 전체 모듈을 가져오고 싶을 경우
//------ main.js ------
import * as lib from 'lib';
console.log(lib.square(11)); // 121
console.log(lib.diag(4, 3)); // 5

 

CJS에서는 다음과 같이 동일하게 작성 가능하다.

//------ lib.js ------
var sqrt = Math.sqrt;
function square(x) {
    return x * x;
}
function diag(x, y) {
    return sqrt(square(x) + square(y));
}
module.exports = {
    sqrt: sqrt,
    square: square,
    diag: diag,
};

//------ main.js ------
var square = require('lib').square;
var diag = require('lib').diag;
console.log(square(11)); // 121
console.log(diag(4, 3)); // 5

 

default exports 사용

// 함수 default export 
//------ myFunc.js ------
export default function () {} // no semicolon!

//------ main1.js ------
import myFunc from 'myFunc';
myFunc();


// 클래스 default export 

//------ MyClass.js ------
export default class {} // no semicolon!

//------ main2.js ------
import MyClass from 'MyClass';
const inst = new MyClass();

// 선언 label 방식
export default function foo() {} // no semicolon!
export default class Bar {} // no semicolon!

// default-export 값을 직접 export 하기
export default function () {} // no semicolon! (익명함수를 활용)
export default class {} // no semicolon!
export default 'abc';
export default foo();
export default /^xyz$/;
export default 5 * 7;
export default { no: false, yes: true };

 

default exports 방식을 보면 default exports의 피연산자 (export 하는 대상)이 표현식일 거라고 생각할 수도 있다.

하지만 표현식이 아닌 선언문이다. 표현식으로 해석되기 위해서는 다음과 같이 괄호로 감싸줘야 한다.

export default (function () {});

 

ESM export/import 선언은 최상단에

 

ESM은 정적 모듈을 지원한다고 했다. 즉, 조건부적으로 import/export를 결정할 수 없다. 

따라서 해당 스코프의 최상단에 위치시켜줘야 한다.

 

ESM import 은 호이스팅된다

 

import 한 모듈은 현재 스코프의 최상단으로 끌어올려지는 호이스팅이 발생한다.

 

ESM import 된 값은 export 한 값의 읽기 전용 LIVE(변경사항이 즉각 반영된) 값이다

 

CJS와 달리 ESM은 순환 dependency를 다루기 용이하다고 했는데, 바로 export 한 ESM은 읽기 전용(read-only)이기 때문이다.

읽기 전용이라는 게 무슨 의미일까?  import 해온 값의 변경 사항이 곧바로 반영되는 다음 예를 살펴보자.

//------ lib.js ------
export let counter = 3;
export function incCounter() {
    counter++;
}

//------ main.js ------
import { counter, incCounter } from './lib';

// import 해온 값 value `counter`는 변경 사항이 곧바로 적용된다
console.log(counter); // 3
incCounter();
console.log(counter); // 4

 

CJS는 import 해온 값이 복사본인 반면, ESM은 export한 값이 바인딩된 값이라고 했다.

바인딩된 값은 변경 사항을 즉각 반영한 export 한 값의 읽기 전용 값이다. 

 

읽기 전용으로 값을 import해오면 import작업이 양방향이게 된다.

따라서 여러 개의 모듈로 코드를 split해도 import 값을 변경하지 않는 이상 원래대로 작동하고,  

순환 dependency가 발생하는 경우와 같이 비정상적(?)인 import도 지원해 준다.

 

🤔 근데 애초에 순환 dependency가 발생하지 않게 하면 되는 거 아닌가? 싶을 수 있다. 

이에 관해서는 다음에서 다뤄보자.

👻 순환 dependency는 나쁜 것만은 아니다. 특히 객체를 다룰 때 이런 dependency를 오히려 선호할 수도 있다.
예를 들면, DOM 객체와 같이 부모와 지식 간에 참조가 필요할 수도 있다.
일반적으로 라이브러리의 경우 순환 dependency는 디자인에 신중을 가하면 피할 수는 있다.
하지만 시스템이 커지고, 특히 리펙터링 도중에는 순환 dependency가 발생할 수 있다.
모듈 시스템이 순환 dependency를 지원하면 시스템이 고장 나지 않고도 작업을 할 수 있어서 유용하다.

 

 

ESM 은 순환 dependency를 지원한다

 

모듈 A와 B가 서로를 import 하고 있는 경우 순환 dependency를 지녔다고 할 수 있다.

가능하다면 순환 dependency는 모듈 간의 결합도(coupling)을 높여 모듈 분리의 목적을 헤치므로 지양해야 한다.

 

하지만 불가피할 경우에 순환 dependency가 발생할 수 있기 때문에 모듈 시스템은 이를 지원을 해야 한다.

 

다음은 CJS와 ESM이 각각 순환 dependency를 다루는 방식이다.

다만 어느 모듈이든 간에 순환 dependency가 있다면 모듈 body 내부에서 import에 접근 불가능하다는 점을 기억하자.

// CJS에서의 순환 dependency 핸들링
//------ a.js ------
var b = require('b');
function foo() {
    b.bar();
}
exports.foo = foo;

//------ b.js ------
// a가 번저 b에서 import되면 export가 추가되기 전에 a의 object를 받는다
// 따라서 b는 a.foo룰 최상단이 아닌 a의 실행이 끝나고 프로퍼티가 존재한 뒤에서야 접근 가능하다.
var a = require('a'); 
function bar() {
    if (Math.random()) {
        a.foo(); // bar()이 그 후 호출되면 실행
    }
}
exports.bar = bar;

 

CJS 방식에는 다음과 같은 문제점들이 있다.

1. node.js 스타일의 단일 값 export를 사용할 수 없다. object 대신 단일 값을 export 해야 한다.

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

 

앞서 살펴본 예에서 만약에 모듈 a 가 위와 같이 export 된다면, b의 변수 a는 할당이 되기 전까지 업데이트가 반영되지 않게 된다. 

2.  named exports를 직접 사용할 수 없다. 즉, 모듈 b는 다음과 같이 foo를 import 할 수 없기 때문에 a.foo로 참조할 수밖에 없다.

  var foo = require('a').foo; // undefined

 

핵심은 import를 하는 모듈과 export를 하는 모듈 모두 순환 dependency에 대한 명시적 처리를 해줘야 한다는 점이다.

 

돌아와서 ESM이 순환 dependency를 처리하는 방식을 살펴보면, 다음과 같이 자동적으로 지원을 해준다는 걸 알 수 있다.

//------ a.js ------
import {bar} from 'b'; // b 모듈의 bar의 읽기-전용 버전 import
export function foo() {
    bar(); // 읽기 전용의 값, 오리지널 데이터 bar를 간접적으로 참조
}

//------ b.js ------
import {foo} from 'a'; // a모듈의 foo를 읽기-전용 버전으로 import
export function bar() {
    if (Math.random()) {
        foo(); // foo의 오리지널 데이터를 간접적으로 참조 
    }
}

 

import는 읽기-전용의 값을 가져온다는 점을 통해 순환 dependency가 있어도 항상 오리지널 데이터를 찾아가도록 보장한다.

 

ESM로 import 한 값은 export 값의 읽기-전용 LIVE 버전, CJS는 export 값의 복사본을 import 한다

 

복사본을 import 해서 발생하는 CJS의 문제점을 살펴보자.

//------ lib.js ------
var counter = 3;
function incCounter() {
    counter++;
}
module.exports = {
    counter: counter, // (A)
    incCounter: incCounter,
};

//------ main1.js ------
var counter = require('./lib').counter; // (B)
var incCounter = require('./lib').incCounter;

// import한 값은 복사본의 복사본이다 
console.log(counter); // 3
incCounter();
console.log(counter); // 3

// import한 값을 변경할 수 있다.
counter++;
console.log(counter); // 4

 

export 한 객체의 값에 접근하게 되면 또다시 export시에 복사되어 복사본이 import 사용처에 전달된다.

반면에 ESM에서는 export값의 읽기 전용으로 LIVE(변경사항이 즉각 반영된 값)이 전달된다.

다음 예를 살펴보자.

//------ lib.js ------
export let counter = 3;
export function incCounter() {
    counter++;
}

//------ main1.js ------
import { counter, incCounter } from './lib';

// import한 값 counter는 라이브(변경사항이 즉각 반영된) 값이다.
console.log(counter); // 3
incCounter();
console.log(counter); // 4

// 읽기 전용 값인 import된 counter을 변경할 수 없다.
counter++; // TypeError

 

다만, import값의 객체 속성은 변경가능하다.

//------ lib.js ------
export let obj = {};

//------ main.js ------
import { obj } from './lib';

obj.prop = 123; // OK
obj = {}; // TypeError

 

ESM는 정적(static) 모듈 구조를 강제한다

 

현재 자바스크립트 모듈은 동적 구조를 띤다. 따라서 런타임에 어떤 모듈이 import/export 되는지 동적으로 변할 수 있다.

정적 모듈 구조를 지녔다는 것은  컴파일 시기에 import/export를 결정할 수 있다는 것이다.

이는 코드를 실행하지 않아도 import/export 값을 바로 알 수 있다는 것이다.

 

반면에 CJS는 정적 모듈 구조를 지원하지 않는다.  다음 예시를 살펴보자.

코드를 실행해야지만 어떤 값이 import 될지 알 수 있다.

var my_lib;
if (Math.random()) {
    my_lib = require('foo');
} else {
    my_lib = require('bar');
}

 

다음 예시 또한 실행을 해야지만 어떤 값이 export 되는지 알 수 있다.

if (Math.random()) {
    exports.baz = ···;
}

 

 

반면 ESM이 정적 모듈의 지원해서 발생하는 장점은 다음과 같다.

 

1. tree shaking (번들링 중 죽은 코드 제거)

 

프론트엔드 개발에서 모듈은 주로 다음과 같이 핸들링된다 :

- 개발 도중 아주 많고 주로 작은 모듈로 코드가 작성된다.

- 배포를 위해서 이 모듈들은 적고, 상대적으로 큰 파일들로 번들링 된다. 

 

번들링은 왜 할까?

 1. 모든 모듈을 로드하기 위한 파일들을 찾기 위한 수고를 덜 수 있다. ➡ 파일 요청 비용이 상대적으로 높은 HTTP/1에서 중요, HTTP/2에서는 해결

 2. 번들링 된 파일을 압축하는 것이 여러 개의 파일을 압축하는 것보다 효율적이다. 

 3. 번들링 도중 사용되지 않은 export는 제거할 수 있고 용량을 상당히 줄일 수 있다. ➡ 정적 구조의 모듈 시스템에서만 지원

 

2. compact 번들링, 커스텀 번들링 형식 없음

Rollup 모듈 번들러는 중복된 변수명을 변경하고, ESM을 효율적으로 하나의 스코프로 통합할 수 있다는 걸 보여줬다.

이는 정적 구조를 지녔기 때문에 번들 포맷이 조건부적으로 모듈이 로드되는 상황을 고려하지 않을 수 있고,

읽기-전용 export 값을 import 해온다는 점에서 export를 복사하지 않아서 직접 참조할 수 있기 때문에 가능하다.

 

다음 예에서 Rollup이 번들링 과정에서 사용하지 않은 export를 tree shaking 하는 예를 살펴보자.

 

👥 번들링 이전

// lib.js
export function foo() {}
export function bar() {}

// main.js
import {foo} from './lib.js';
console.log(foo());

 

👤 번들링 이후 : 사용되지 않은 export bar는 제거되었다.

function foo() {}

console.log(foo());

 

3. import lookup이 더 빠르다.

 

이전에 다루었듯이, CJS로 된 라이브러리에서  require로 값을 가져오면 object을 반환받는다.

var lib = require('lib');
lib.someFunc(); // property lookup

 

따라서 값의 property에 접근하기 위해서는 property lookup을 해야 하는데, 동적으로 이루어지기 때문에 느리다.

반면에 ESM로 된 라이브러리를 import 해오는 경우 정적으로 모든 콘텐츠를 알 수 있고 최적화된 접근이 가능하다.

import * as lib from 'lib';
lib.someFunc(); // statically resolved

 

뿐만 아니라 ESM는 변수 체크, macro 혹은 타입 적용에 친화적이다는 장점도 지녔다.

🍱 TAKEAWAYS

모듈 시스템에는 크게 두 가지 CJS와 ESM 가 있다. 
CJS는 require와 module.exports로, ESM 은 import과 export으로 모듈을 가져오고 내보낸다.
ESM이 CJS에 비해 지닌 이점들이 여럿 있는데, 이 중에 tree shaking과 순환 dependency 지원이 중요하다고 꼽을 수 있다.
이는 ESM이 정적 구조로 런타임 이전에 import과 export를 알 수 있어, 죽은 코드를 제거하기 용이하게 됩니다.
또한 ESM은 export의 복사본 객체를 import 하는 CJS와 달리,
export 값의 읽기 전용 LIVE 값을 import 한다는 점에서 자동적으로 순환 dependency를 지원해 준다는 점에서 장점을 지니고 있습니다.

👩🏻‍💻TMI

글이 길어질 거 같아서 번들링 관련은 다음에 다뤄야 할 거 같다.

모듈 시스템에 대해 잘 모르고 넘어간 부분을 보고 갈 수 있었던 시간이었다.

 

📚 References

https://www.freecodecamp.org/news/anatomy-of-js-module-systems-and-building-libraries-fadcd8dbd0e/

Learn the basics of the JavaScript module system and build your own library

https://exploringjs.com/es6/ch_modules.html#static-module-structure

16. Modules