13장 모듈

2023.06.16

13.1 모듈 소개

  • 모든 규모의 프로젝트에서 프로그래머는 이름 충돌, 복잡한 종속성 및 코드를 적절한 크기의 파일로 분할하는 문제에 직면하게 된다.
  • 이러한 문제로 인해 CommonJS(cjs), 비동기식 모듈 정책 (Asynchronous Module Definition. AMD), 그 변형과 같은 코드 모듈을 정의하고 결합하기 위한 다양한 서로 다른 호환되지 않는 솔루션이 탄생했다.
  • ES2015는 자바스크립트용 모듈을 표준화하여 도구와 작성자가 사용할 수 있는 대부분의 공통 구문과 의미론을 제공한다.
  • 이전 모듈 방식의 이름 목록과 유사하게 기본 모듈은 CJS 모듈, AMD 모듈 또는 기타 유형과 구별되는 ESM 모듈(ECMAScript Module)이라고 하는 경우가 많다.

13.2 모듈 기초

  • 모듈은 자체 컴파일 단위(느슨하게는 "파일”)에 있는 코드 단위이다.
  • 모듈은 자체 스코프가 있다.
  • 다른 모듈에서 임포트를 통하여 다른 모듈을 로드할 수 있다.
  • 다른 모듈이 임포트한 엔트리를 익스포트할 수 있다.
  • 각각의 익스포트를 가져오는 모듈 그룹은 일반적으로 모듈 트리라고 하는 그래프를 형성한다.
  • 임포트할 때 모듈을 찾을 위치를 나타내는 문자열인 모듈 지정자(module specifier)를 사용하여 임포트할 모듈을 지정한다.
  • 자바스크립트 엔진은 호스트 환경과 함께 작동하여 지정한 모듈을 로드한다.
  • 자바스크립트 엔진은 영역(ex. 브라우저 창)당 한 번만 모듈을 로드한다.
  • 여러 다른 모듈에서 사용하는 경우 모두 동일한 복사본을 사용한다.
  • 모듈은 명명된 익스포트 및/또는 단일 기본 익스포트를 가질 수 있다.
  • 모듈의 코드는 전역 스코프에서 실행되지 않기 때문에 모듈은 전역 변수를 선언할 수 없다.
  • 익스포트를 임포트하면 임포트한 엔트리에 대한 읽기 전용 라이브 간접 바인딩(indirectbinding)이 생성된다.

13.2.1 모듈 지정자

1import { example } from './mod.js';
  • 위의 예에서 ‘./mod.js’ 부분은 모듈 지정자이다.
  • 임포트 선언에서 모듈 지정자는 문자열을 생성하는 표현식이 아니라 문자열 리터럴이어야 한다.
  • 선언은 정적 양식이기 때문이다. 자바스크립트 엔진과 환경은 코드를 실행하지 않고도 이를 해석할 수 있어야 한다.

13.2.2 명명된 익스포트 기초

  • 명명된 익스포트를 사용하여 변수, 상수, 함수, 클래스 생성자, 다른 모듈에서 가져온 엔트리와 같이 이름이 있는 모든 모듈 내에서 선언된 모든 엔트리를 익스포트할 수 있다.
1export let answer = 42;
2export var question = 'Life';
3export const author = 'coder';
4export function fn() {}
5export class Example {}
  • 익스포트 이름은 고유해야 한다.

13.2.3 기본 익스포트

  • 명명된 익스포트 외에도 모듈은 선택적으로 단일 기본 익스포트를 가질 수도 있다.
  • 기본 익스포트는 default라는 이름을 사용하는 명명된 익스포트와 같지만 고유한 전용 구문이 있으며 export 뒤에 키워드 default를 추가하여 기본 익스포트를 설정한다.
1export default function example() {}
  • 모듈은 하나의 기본 익스포트만 가질 수 있다.
1export default 6 * 7;
  • 위 기본 익스포트는 모듈 코드가 접근하는 데 사용할 수 있는 식별자가 없다는 점만 제외하면 let 익스포트와 똑같다.
  • 표현식을 평가하므로 let 익스포트와 마찬가지로 코드의 단계별 실행에서 익스포트 선언에 도달할 때까지 값이 존재하지 않는다. 그떄까지는 TDZ에 있다.

13.2.4 브라우저에서 모듈 사용하기

  • script 요소의 코드가 모듈임을 브라우저에 알리려면 type=”module”을 사용한다.
1<script src='main.js' type='module'></script>
  • 모듈 스크립트는 구문 분석을 지연시키지 않는다.
  • 모듈과 그 종속성은 구문 분석과 병렬로 로드된다. 그런 다음 모듈의 코드는 구문 분석이 완료될 때 실행된다.
  • defer 속성과 차이점은 defer는 인라인 콘텐츠가 있는 스크립트 태그가 아니라 src 속성을 통해 외부 리소스에서 콘텐츠를 로드하는 스크립트만 지연시킨다. 그러나 type=”module”은 인라인 콘텐츠가 있는 스크립트도 연기한다.
  • 모듈의 코드는 HTML 구문 분석이 완료될 때까지 실행되지 않지만 브라우저와 자바스크립트 엔진은 함께 작동하여 모듈의 종속성을 확인하고(import 선언에서) 모듈이 의존하는 모든 모듈을 HTML 구문 분석과 병렬로 가져온다.
  • 모듈 지정자는 절대 URL이거나 상대 URL이다.
1import /* .... */ 'http://example.com/a.js';
2import /* .... */ '/a.js';
3import /* .... */ './a.js';
4import /* .... */ '../modules/d.js';
  • 많은 개발자가 확장자로 .js를 고수하지만, 일부는 파일에 스크립트뿐만 아니라 모듈이 포함되어 있다는 사실을 알리기 위해 .mjs를 선택하고 있다.
  • 모듈에는 고유한 MIME 유형이 없기 때문에 text/javascript로 파일을 제공하도록 웹 서버를 구성해야 한다.

13.2.5 노드제이에스에서 모듈 사용하기

  • 노드제이에스는 CJS 모듈 외에도 자바스크립트의 기본 모듈(ESM)을 지원한다.
  • ESM을 사용할 때 아래와 같이 세 가지 방법 중 하나를 설정해야 한다.
    • 프로젝트의 package.json의 type 필드를 “module” 값으로 만든다.
    • ESM 모듈 파일에서 .mjs를 파일 확장자로 사용한다.
    • 문자열을 노드에 전달할 때 —input-type=module을 지정한다.
  • package.json의 type 필드와 상관 없이 .cjs 확장자 파일을 임포트하면 해당 파일을 CJS 모듈로 로드한다.
  • 모듈 파일을 임포트할 때 노드제이에스의 모듈 지정자는 기본적으로 웹에 정의된 것과 매우 유사하다. URL이 아닌 절대 또는 상대 파일 이름이며 파일 확장자가 필요하다.
  • node_modules에 설치된 패키지를 임포트할 때 이름만을 사용한다.
1import { writeFile } from 'fs';

13.3 익스포트를 다시 이름 짓기

  • 모듈에서 내보내는 식별자가 모듈 코드 내에서 사용하는 식별자와 같을 필요는 없다.
  • 익스포트 선언 내에서 as 절을 사용하여 익스포트 이름을 바꿀 수 있다.
1let namewithinModule = 42:
2export {exportedName as nameWithinModule };
  • exportName이라는 이름을 사용하여 다른 모듈에서 가져올 수 있다.
1import { exportedName } from './mode.js';
  • nameWithinModule은 모듈 외부가 아니라 모듈 내에서만 사용하기 위한 것이다.
  • 이름 바꾸기 구문을 사용하여 기본 익스포트도 만들수 있지만 좋은 방법은 아니다.
1export { expandStart as default };
  • 기본 익스포트는 default라는 익스포트 이름을 사용하는 명명된 익스포트와 같다.
1export default expandStart;

13.4 다른 모듈의 익스포트를 다시 익스포트하기

  • 모듈은 다른 모듈의 익스포트를 다시 익스포트할 수 있다. 이를 간접 익스포트(indirect export)라고 한다.
1export { example } from './example.js';
  • 이것이 유용한 곳은 롤업 모듈이다. 모든 코드가 사용되지 않음에도 모듈의 모든 코드를 메모리로 임포트하는 것을 방지하기 위해 필요한 부분만 임포트하도록 하는 것이다. ( 트리셰이킹)
  • 다른 모듈에 명명된 모든 익스포트를 익스포트하기라는 별표(*)를 사용하는 특별한 형태가 있다.
1export * from './lib-a.js';
2export * from './lib-b.js';
  • 이는 유지 보수시 더 편리함을 제공한다. ( 엔트리 추가시, 추가적인 업데이트 비용이 발생하지 않으므로 )

13.5 임포트를 다시 이름 짓기

  • as 절을 사용하여 임포트 이름을 바꿀 수 있다.
1import { example as aExample } from './a.js';
2import { example as bExample } from './b.js';
  • 기본 익스포트를 임포트할 때 항상 고유한 이름을 선택하므로 as 절은 관련이 없다.
1import someName from '/.mod.js';
2import someOtherName from '/.mod.js';
3
4console.log(someOtherName === someName); // true
  • export의 이름 바꾸기 양식과 마찬가지로 import의 이름 바꾸기 양식을 사용하여 원하는 경우 기본 익스포트를 임포트할 수도 있지만 모범 사례는 아니다.
1import { default as someOtherName };

13.6 모듈의 네임스페이스 객체 임포트하기

  • 개별 익스포트를 임포트하는 대신 전체 모듈에 대한 모듈 네임스페이스 객체를 임포트할 수 있다.
1// module.js
2export function example() {
3  console.log('example called');
4}
5export const something = 'something';
6export default function () {
7  console.log('default called');
8}
9
10// use.js
11import * as mod from './module.js';
12mod.example(); // example called
13mod.something; // something
14mod.default(); // default called
  • 모듈 네임스페이스 객체는 모듈과 동일하지 않다. 모듈의 모든 익스포트에 대한 속성을 사용하여 처음 요청될 때 생성되는 별도의 객체이다.
  • 모듈 네임스페이스 객체가 생성되면 다른 모듈이 모듈의 네임스페이스 객체를 가져오는 경우에도 재사용된다.
  • 객체는 읽기 전용이며, 속성을 쓰거나 추가할 수 없다.

13.7 다른 모듈의 네임스페이스 객체 익스포트하기

  • ES2020의 규범적 변경에 따라 모듈은 다른 모듈의 네임스페이스 객체를 임포트해서 익스포트를 할 수 있다.
1export * as stuff from './module2.js';

13.8 단지 사이드 이펙트를 위해 모듈 임포트하기

  • 모듈에서 아무것도 가져오지 않고 모듈을 로드하고 실행하기 위해 임포트할 수 있다.
1import './mod.js';
  • mod.js를 로드하면 최상위 코드가 실행되므로, 이는 최상위 코드에 있을 수 있는 부작용에 대해 모듈만 임포트할 때 유용하다.
  • 일반적으로 모듈의 최상위 코드에 부작용이 없는 것이 가장 좋지만 예외를 만드는 것이 적절한 경우에 따라 모듈의 최상위 코드를 실행하게 하는 방법을 제공한다.

13.9 임포트와 익스포트 엔트리

  • 자바스크립트 엔진이 모듈을 구문 분석할 때 모듈의 임포트 엔트리 목록과 익스포트 엔트리 목록을 작성한다.

13.9.1 임포트 엔트리

  • 임포트 엔트리에는 세 개의 필드가 있다.
    • [[ModuleRequest]]: 임포트 선언의 모듈 지정자 문자열이며 임포트가 어떤 모듈에서 오는지 알려준다.
    • [[ImportName]]: 임포트한 것의 이름이며 모듈 네임스페이스 객체를 임포트하는 경우 * 이다.
    • [[LocalName]]: 임포트한 엔트리에 사용할 로컬 식별자(바인딩)의 이름이다. 종종 [[ImportName]]과 동일하지만 임포트 선언에서 as를 사용하여 임포트 이름을 바꾼 경우에는 다를 수 있다.
1| 임포트 명령문 양식             | [[ModuleRequest]]                     | [[ImportName]] | [[LocalName]] |
2| ------------------------------ | ------------------------------------- | -------------- | ------------- |
3| `import v from 'mod';`         | "mod"                                 | `default`      | `v`           |
4| `import * as ns from 'mod';`   | "mod"                                 | `*`            | `ns`          |
5| `import { x } from 'mod';`     | "mod"                                 | `x`            | `x`           |
6| `import { x as v} from 'mod';` | "mod"                                 | `x`            | `v`           |
7| `import 'mod';`                | ImportEntry 레코드가 생성되지 않는다. |

13.9.2 익스포트 엔트리

  • 익스포트 엔트리에는 네 개의 필드가 있다.
    • [[ExportName]]: 익스포트의 이름이다. 임포트할 때 다른 모듈이 사용하는 이름이다. 기본 익스포트에 대한 문자열 "default"이다. 다른 모듈에서 모든 것을 다시 익스포트하는 export * from 선언의 경우 null이다.
    • [[LocalName]]: 익스포트하는 로컬 식별자(바인딩)의 이름이다. 이것은 종종 [[ExportName]]과 동일하지만 익스포트 이름을 변경한 경우 다를 수 있다. 관련된 로컬 이름이 없기 때문에 이 엔트리가 다른 모듈의 익스포트를 다시 익스포트하는 export .... from 선언에서 익스포트를 위한 것이라면 이것은 null이다.
    • [[ModuleRequest]]: 다시 익스포트하는 경우 export ... from 선언의 모듈 지정자 문자열이다. 모듈 자체 익스포트의 경우 null이다.
    • [[ImportName]]: 다시 익스포트하는 경우 다시 익스포트할 다른 모듈의 익스포트 이름이다. 종종 이것은 [[ExportName]]과 동일하지만 다시 익스포트 선언에서 as 절을 사용한 경우 다를 수 있으며, 모듈 자체 익스포트의 경우 null이다.
    1| 익스포트 명령문 양식              | [[EXPORTNAME]] | [[ModuleRequest]] | [[ImportName]] | [[LocalName]] |
    2| --------------------------------- | -------------- | ----------------- | -------------- | ------------- |
    3| `export var v;`                   | `v`            | null              | null           | `v`           |
    4| `export default function f() {};` | `default`      | null              | null           | `f`           |
    5| `export default function () {};`  | `default`      | null              | null           | `*default*`   |
    6| `export default 42;`              | `default`      | null              | null           | `*default*`   |
    7| `export { x };`                   | `x`            | null              | null           | `x`           |
    8| `export { v as x };`              | `x`            | null              | null           | `v`           |
    9| `export { x } from 'mod';`        | `x`            | "mod"             | `x`            | null          |

13.10 임포트는 살아있고 읽기 전용이다

  • 모듈에서 무언가를 임포트할 때 원본 엔트리에 대한 간접 바인딩이라고 하는 읽기 전용 라이브 바인딩을 얻는다.
  • 읽기 전용이므로 코드에서 바인딩에 새 값을 할당할 수 없다. 하지만 라이브 바인딩이기 때문에 코드는 원래 모듈이 할당한 새 값을 볼 수 있다.
1// mode.js
2const a = 1;
3let c = 0;
4export { c as counter };
5export function increment() {
6  ++c;
7}
8
9// main.js
10import { counter, increment as inc } from './mod.js';
11console.log(counter); // 0
12inc();
13console.log(counter); // 1
14counter = 42; // TypeError: Assignment to constant variable.
  • main.js의 코드는 mod.js가 수행하는 카운터 변경 사항을 확인하지만 값을 직접 설정할 수는 없다.
  • 각 모듈에는 모듈 환경 객체가 있다. 모듈 환경 객체에는 해당 모듈의 모든 익스포트와 임포트에 대한 바인딩이 있다.

13.11 모듈 인스턴스는 영역 전용이다

  • 모듈은 영역(창, 탭, 워커 등)당 한 번만 로드된다.
  • 특히 자바스크립트 엔진은 영역 내에서 로드된 모듈을 추적하고 두 번 이상 요청된 모듈을 재사용한다. 거꾸로 말하면 영역이 다르면 모듈 인스턴스도 다르다.
  • 다른 영역은 모듈 인스턴스를 공유하지 않는다.
  • 모듈은 영역 간에 공유되지 않고 영역 내에서만 공유된다.

13.12 어떻게 모듈을 읽어 오는가?

  • 자바스크립트 모듈 시스템은 간단한 사용 사례를 단순하게 유지하지만 복잡한 사용 사례를 잘 처리하도록 설계되었다. 이를 위해 모듈은 세 단계로 로드된다.
    • 임포트와 구문 분석: 모듈의 소스 텍스트를 임포트하고 구문 분석하여 임포트 및 익스포트를 결정한다.
    • 인스턴스화: 모든 임포트 및 익스포트에 대한 바인딩을 포함하여 모듈의 환경 및 바인딩을 생성한다.
    • 평가: 모듈의 코드를 실행한다.

13.12.1 임포트와 구문 분석

  • 모듈이 아닌 스크립트와 달리 모듈 스크립트는 HTML 파서를 멈추게 하지 않으므로 HTML 파서는 모듈을 파싱하고 로드하는 작업이 완료되는 동안 계속된다.
  • 특히 모듈 스크립트는 기본적으로 지연된다(defer 속성이 있는 것처럼).
  • 이는 HTML 파서가 페이지 구문 분석을 완료할 때까지 해당 코드가 평가되지 않음을 의미한다.
  • HTML 파서가 완료되기 전에도 평가가 가능한 한 빨리 발생하도록 하려면 대신 async를 지정할 수 있다.
  • 브라우저가 entry.js의 내용을 자바스크립트 엔진에 전달할 때 엔진은 이를 구문 분석하고 이에 대한 모듈 레코드를 생성한다.
  • 모듈 레코드에는 구문 분석된 코드, 이 모듈에 필요한 모듈 목록, 임포트 엔트리익스포트 엔트리 목록, 모듈상태(로드와 평가 과정에 있음)가 들어간다.
1<img className='w-8/12 m-auto' src='/assets/images/web-javascript-1.jpg' />
2<br />
  • 자바스크립트 엔진은 해당 모듈 레코드를 호스트에 반환하고, 호스트는 이를 완전히 확인된 모듈 지정자 아래의 확인된 모듈 맵에 저장한다.
    • 나중에 모듈 레코드가 필요할 때 자바스크립트 엔진은 호스트에게 요청한다.\
    • 호스트는 모듈 맵에서 찾아보고 발견하면 반환한다.
    • 이 시점에서 entry.js가 임포트해서 구문 분석되었으므로 자바스크립트 엔진은 entry.js의 인스턴스화 단계를 시작한다.
    • 기본적으로 가장 먼저 하는 일은 브라우저에 modl js와 mod2.js를 확인하도록 요청하는 것이다. 임포트하여 구문 분석되면 브라우저에는 세 가지 모듈 모두에 대한 엔트리가 있는 모듈맵이 있다.
    • 모듈 레코드의 정보를 통해 자바스크립트 엔진은 인스턴스화와 평가해야 하는 모듈 트리를 결정할 수 있다. 트리는 아래 그림과 같다.
1<img className='w-8/12 m-auto' src='/assets/images/web-javascript-2.jpg' />
2<br />

13.12.2 인스턴스화

  • 이 단계에서 자바스크립트 엔진은 모듈의 모든 임포트와 익스포트에 대한 바인딩을 포함하여 각 모듈의 환경 객체와 그 안에 최상위 바인딩을 만든다.
    • 로컬의 경우 직접 바인딩이다.
    • 임포트의 경우 엔진이 익스포트를 위한 익스포트 모듈의 바인딩에 연결하는 간접 바인딩이다.
  • 인스턴스화는 최하위 모듈이 먼저 인스턴스화되도록 깊이 우선 탐색을 사용하여 수행된다.
  • 모듈을 인스턴스화하면 해당 범위가 생성되지만 해당 코드는 실행되지 않는다. 즉, 호이스트 가능한 선언이 처리되어 그에 대한 함수가 생성되지만 어휘 바인딩은 초기화되지 않은 상태로 남는다. 이러한 선언은 TDZ에 있다.

13.12.3 평가

  • 이 단계에서 자바스크립트 엔진은 모듈의 최상위 코드를 다시 깊이 우선 순서로 실행하여 각 모듈을 "평가됨"으로 표시한다.
  • 코드가 실행되면 모든 최상위 초기화되지 않은 바인딩이 코드 실행에 도달하면 초기화된다.
  • 자바스크립트 모듈 시스템은 각 모듈의 최상위 코드가 한 번만 실행되도록 한다.
  • 브라우저에서 엔트리 포인트에 대한 script 태그에 async 속성이 없으면 HTML 파서가 문서 구문 분석을 완료할 때까지 평가가 시작되지 않는다.
  • async 속성이 있으면 HTML 파서가 문서에서 계속 작업 중이더라도 인스턴스화가 완료된 후 최대한 빨리 평가가 시작된다.

13.12.4 임시 데드존(TDZ)를 정리하며

  • TDZ는 호이스트 가능한 선언이 아니라 어휘 바인딩에만 관련된다.
    • 호이스트 가능한 선언은 var 선언, 함수 선언이 있다.
  • TDZ는 환경 객체가 생성되고 모듈에 대한 환경을 포함하여 해당 바인딩을 임포트할 때마다 적용된다.
  • 모듈에 대한 환경 객체는 모듈 인스턴스화 중에 생성되고 해당 코드는 나중에 모듈 평가 중에 실행된다.
  • 모듈이 최상위 범위에 있는 모든 어휘 바인딩은 인스턴스화부터 평가 중에 선언에 도달할 때까지 TDZ에 있다.

13.12.5 순환 종속성과 TDZ

1// entry.js
2import { fn1 } from './mod1.js';
3import def, { fn2 } from './mod2.js';
4
5fn1();
6fn2();
7def();
8
9// mod1.js
10import def from './mod2.js';
11
12const indentString = '  ';
13
14export function indent(nest = 0) {
15  return indentString.repeat(nest);
16}
17
18export function fn1(nest = 0) {
19  console.log(`${indent(nest)}mod1 - fn1`);
20  def(nest + 1);
21}
22
23// mod2.js
24import { fn1, indent } from './mod1.js';
25
26export function fn2(nest = 0) {
27  console.log(`${indent(nest)}mod2 - fn2`);
28  fn1(nest + 1);
29}
30
31export default function (nest = 0) {
32  console.log(`${indent(nest)}mod2 - default`);
33}
  • 위의 예에서 mod1.js와 mod2.js는 서로를 참조한다. 즉 순환 종속성에 있다.
  • 모듈을 로드하고 평가하는 3단계 프로세스 때문에 자바스크립트 모듈 시스템에서는 문제가 되지 않는다.
  • mod1.js, mod2.js 모두 함수 호출에 대한 응답으로 임포트한 것만 사용한다.
  • 아래와 같이 mod2.js를 변경하면 에러가 발생한다.
1import { fn1, indent } from './mod1.js';
2
3console.log(`${indent(0)}hi there`); // ReferenceError
4
5export function fn2(nest = 0) {
6  console.log(`${indent(nest)}mod2 - fn2`);
7  fn1(nest + 1);
8}
9
10export default function (nest = 0) {
11  console.log(`${indent(nest)}mod2 - default`);
12}
  • mod2.js는 mod1.js가 평가되기 전에 indent를 사용하려고 하기 때문이다.

13.13 임포트/익스포트 문법를 정리하며

13.13.1 다양한 방식의 익스포트

  • 다양한 방식의 익스포트 양식에 대한 요약이다.
1export let a;
2export let b = '2';
3export function f() {}
4export class G(){}
5
6export { a };
7export { b };
8export { f as fFunction };
9export { g, f };
10
11export * from './mod.js';
12
13// 기본 익스포트는 하나만 가능하다.
14export default var h = 'hh';
15export default function(){}
16export default class k(){}

13.13.2 다양한 방식의 임포트

  • 다양한 방식의 익스포트 양식에 대한 요약이다.
1import { example } from './mod.js';
2import { example as e } from './mod.js';
3
4import * as mod from './mod.js';
5
6// 기본 임포트
7import example from './mod.js';
8import example, { exampleSecond } from './mod.js';
9
10// 익스포트를 임포트하지 않고 부작용만을 위한 임포트
11import './mod.js';

13.14 동적 임포트

  • 일부 사용 사례에서는 모듈이 런타임에 가져올 엔트리나 위치를 결정해야 한다.
  • ES2020은 동적 임포트를 추가했다.

13.14.1 동적으로 모듈 임포트

  • 동적 임포트는 import가 함수인 것처럼 호출할 수 있는 새로운 구문을 추가한다. 호출되면 import는 모듈의 네임스페이스 객체에 대한 프라미스를 반환한다.
1import(/* ... 일부 런타임-결정 이름 */)
2  .then(ns => /* ... */)
3    .catch(err => /* ... */)
  • 함수 호출처럼 보이지만 import(…)는 함수 호출이 아니다. importCall이라는 새로운 구문이다.
    • 호출은 일반 함수 호출이 전달하지 않는 컨텍스트 정보를 전달해야 한다.
    • 앨리어싱을 허용하지 않으면 정적 분석이 모듈에서 동적 임포트가 사용되는지 여부를 알 수 있다.
    1// 동작하지 않음.
    2const imp = import
    3imp(/* ... 일부 런타임-결정 이름 */)
    4  .then(ns => /* ... */)
    5    .catch(err => /* ... */)
  • 동적으로 로드된 모듈은 정적으로 로드된 모듈과 마찬가지로 캐시된다.

13.14.2 동적 모듈 예

1// dynamic-mod-log.js
2log('log module evaluated');
3export function log(msg) {
4  const p = document.createElement('pre');
5  p.appendChild(document.createTextNode(msg));
6  document.body.appendChild(p);
7}
8
9// dynamic-mod1.js
10import { log } from './dynamic-mod-log.js';
11import { showTime } from './dynamic-mod-showtime.js';
12
13log('dynamic module number 1 evaluated');
14export function example(logFromEntry) {
15  log('Number 1! Number 1! Number 1!');
16  log(`log === logFromEntry? ${log === logFromEntry}`);
17  showTime();
18}
19
20// dynamic-mod2.js
21import { log } from './dynamic-mod-log.js';
22import { showTime } from './dynamic-mod-showtime.js';
23
24log('dynamic module number 2 evaluated');
25export function example(logFromEntry) {
26  log("Meh, being Number 2 isn't that bad");
27  log(`log === logFromEntry? ${log === logFromEntry}`);
28  showTime();
29}
1<!doctype html>
2<html>
3<head>
4<meta charset="UTF-8">
5<title>Dynamic Module Loading Example</title>
6</head>
7<body>
8<script src="dynamic-example.js" type="module"></script>
9</body>
10</html>
11
12// dynamic-example.js
13import { log } from "./dynamic-mod-log.js";
14
15log("entry point module top-level evaluation begin");
16(async () => {
17  try {
18    const modName = `./dynamic-mod${Math.random() < 0.5 ? 1 : 2}.js`;
19    log(`entry point module requesting ${modName}`);
20    const mod = await import(modName);
21    log(`entry point module got module ${modName}, calling mod.example`);
22    mod.example(log);
23  } catch (error) {
24    console.error(error);
25  }
26})();
27log("entry point module top-level evaluation end");

13.14.3 비모듈 스크립트의 동적 임포트

  • 정적 임포트와 달리 동적 임포트는 모듈뿐만 아니라 스크립트에서도 사용할 수 있다.
1<!doctype html>
2<html>
3<head>
4<meta charset="UTF-8">
5<title>Dynamic Module Loading in Script - Example</title>
6</head>
7<body>
8<script src="dynamic-example-2.js"></script>
9</body>
10</html>
11
12// dynamic-example-2.js
13(async () => {
14  try {
15    const { log } = await import("./dynamic-mod-log.js");
16    log("entry point module got log");
17    const modName = `./dynamic-mod${Math.random() < 0.5 ? 1 : 2}.js`;
18    log(`entry point module requesting ${modName}`);
19    const mod = await import(modName);
20    log(`entry point module got module ${modName}, calling mod.example`);
21    mod.example(log);
22  } catch (error) {
23    console.error(error);
24  }
25})();
  • 엔트리 포인트와 로그 모듈 간의 관계를 더 이상 정적 분석을 통해 결정할 수 없다.
  • 로그 모듈에서 이름이 지정된 log를 임포트하는 대신 동적 버전이 로그 모듈에 대한 전체 네임스페이스 객체를 임포트한다.
  • 대조적으로 정적 예에서는 모듈 네임스페이스 객체가 생성되지 않는다. 아무것도 요구하지 않기 때문이다.

13.15 트리 셰이킹

  • 트리 셰이킹(tree shaking)은 데드 코드 제거(dead code elimination)의 한 형태이다.
  • 트리 셰이킹은 모듈 트리를 분석하여 데드 코드를 제거하는 프로세스이다.
  • 트리 셰이킹은 브라우저의 모듈에 대한 기본 지원에도 불구하고 가까운 장례에 자바스크립트 번들러가 사라지지 않는 한 가지 이유이다.
  • 트리의 모든 모듈에서 문자열 리터럴 이외의 다른 것과 함께 import()를 한 번만 사용하더라도 도구는 실제로 사용되지 않는 것을 증명할 수 없기 때문에 트리 셰이킹을 수행할 수 없다.
  • 다른 번들러는 다양한 방식으로 동적 임포트의 영향을 최적화하고 트리 셰이크를 시도할지 여부와 시도 방법을 제어할 수 있는 구성 옵션을 제공할 수 있다.

13.16 번들링

  • 모듈은 현재 최신 브라우저에서 기본적으로 지원되지만 사람들은 모듈을 지원하지 않는 브라우저에서 작동하는 최적화된 파일로 모듈을 변환하기 위해 자바스크립트 번들러를 사용하여 한동안 구문을 사용해 왔다.
  • 모든 규모의 프로젝트에서 기본 모듈 지원이 있는 브라우저만 대상으로 하는 경우에도 번들러를 사용하고 싶을 것이다. 트리 셰이킹도 한 가지 이유이다.
  • 다른 하나는 HTTP(심지어 HTTP/2 포 함)를 통해 모든 개별 모듈 리소스를 전송하는 것이 단일 리소스를 전송하는 것보다 여전히 잠재 적으로 느리다(HTTP/1.1만 사용하는 경우 확실히 느리다).
  • 구글은 두 개의 인기 있는 실제 라이브러리(Moment.js와 Three.js)와 합성적으로 생성된 많은 모듈을 사용하여 기본 모듈 로딩과 로딩 번들을 비교하여 번들링이 여전히 유용한지 여부와 크롬 로딩 파이프라인에서 병목 현상이 발생한 위치를 확인하는 분석을 수행했다.
  • 분석 결과를 바탕으로 구글의 애디 오스마니와 마티스 바이넌스는 다음을 권장한다.
    • 개발 중에는 기본 지원을 사용한다.
    • 최신 브라우저만 대상으로 하는 100개 미만의 모듈과 얕은 종속성 트리(최대 깊이 5 미만)가 있는 소규모 웹 앱에 대해 프로덕션 환경에서 기본 지원을 사용한다.
    • 그보다 큰 제품이나 모듈 지원이 없는 브라우저를 대상으로 하는 프로젝트를 위해 번들링을 사용한다.
  • 어떤 이유로든 HTTP 1.1을 계속 사용해야 하는 경우에는 어느 쪽이든 장단점이 있다.

13.17 메타데이터 임포트하기

  • 경우에 따라 모듈은 로드된 URL 또는 경로, "주" 모듈인지 등과 같은 자체 정보를 알아야 할 수도 있다. -
  • ES2015의 모듈은 현재 모듈이 해당 정보를 얻을 수 있는 방법을 제공하지 않는다. ES2020은 모듈이 자신에 대한 정보를 얻을 수 있는 방법을 추가했다.
  • 바로 import.meta이다. import.meta는 모듈에 대한 속성을 포함하는 모듈 고유의 객체이다.
  • 속성 자체는 호스트 지정이며 환경(예: browser or node.js)에 따라 다르다.
  • 웹 환경에서 import.meta의 속성은 HTML 사양의 HostGetImportMetaProperties 절에 의해 정의된다. 현재 url이라는 단일 속성만 정의되어 있다.
  • node.js는 모듈의 절대 경로인 URL을 제공하여 url을 지원한다.
  • 시간이 지남에 따라 환경 중 하나 또는 둘 모두에 더 많은 속성이 추가될 것이다.

13.18 워커 모듈

  • 기본적으로 웹 워커는 모듈이 아닌 클래식 스크립트로 로드된다.
  • 워커는 importscripts를 통해 다른 스크립트를 로드할 수 있지만 로드 스크립트와의 통신이 워커의 전역 환경을 통해 이루어지는 구식 방식이다. 그러나 웹 워커는 모듈이 될 수 있으므로 임포트와 익스포트 선언을 사용할 수 있다.

13.18.1 웹 워커를 모듈로 로드하기

  • 워커를 모듈로 로드하여 모듈이 되는 것의 모든 일반적인 이점을 얻으려면 워커 생성자에 두 번째 인수로 전달된 options 객체의 type 옵션을 사용한다.
1const worker = new Worker('/worker.js', { type: 'module' });
  • 모듈 또는 클래식 스크립트 내에서 이 방법으로 워커를 시작할 수 있다. 또한 기존 스크립트 워커와 달리 교차 출처(cross-origin)에서 사용할 수 있도록 하는 교차 출처 리소스 공유(CORS) 정보가 제공되는 경우 모듈 워커를 교차 출처로 실행할 수 있다.
  • 브라우저가 워커를 모듈로 지원하는 경우 워커는 모듈로 로드된다.
1<!DOCTYPE html>
2<html>
3  <head>
4    <meta charset="UTF-8" />
5    <title>Web Worker Module Example</title>
6  </head>
7  <body>
8    <script>
9      const worker = new Worker("./worker-example-worker.js", {
10        type: "module",
11      });
12      worker.addEventListener("message", (e) => {
13        console.log(`Message from worker: ${e.data}`);
14      });
15    </script>
16  </body>
17</html>
18
19// worker-example-worker.js
20import { example } from "./worker-example-mod.js";
21
22postMessage(`example(4) = ${example(4)}`);
23
24// worker-example-mod.js
25export const example = a => a * 2;

13.18.2 노드제이에스 워커를 모듈로 로드하기

  • ESM 모듈에 대한 노드제이에스의 지원은 워커 스레드로 확장된다.
  • 코드를 실행하는 다른 방법과 동일한 규칙이 적용된다. 가장 가까운 package.json 파일에서 type: "module" 설정을 사용하거나 워커에게 .mjs 확장자를 지정하여 워커를 모듈로 시작할 수 있다.

13.18.3 워커는 자신의 영역에 있다

  • 워커가 생성되면 새 영역에 배치된다. 자체 전역 환경, 고유한 객체 등이 있다.
  • 워커가 모듈인 경우 로드하는 모듈은 로드된 모듈과 별도로 해당 영역 내에서 로드된다.
  • 예를 들어, 브라우저에서 기본 창의 모듈이 mod1.js를 로드하고 mod1.js도 로드하는 워커를 시작하는 경우 mod1.js는 기본 창 영역에서 한 번, 워커 영역에서 다시 두 번 로드된다.
  • 이것은 웹 브라우정와 노드제이에스 모두에 해당된다.

13.19 과거 습관을 새롭게

13.19.1 의사 네임스페이스 대신 모듈 사용하기

  • 모듈을 사용하자.
1function privateFunction() {
2  // ...
3}
4
5export function publicFunction() {
6  // ...
7}

13.19.2 스코프 지정 함수에서 코드를 래핑하는 대신 모듈을 사용하기

  • 모듈의 최상위 범위가 전역 스코프가 아니므로 모듈을 사용하자.
1let x = /* ... */;
2function doSomething() {
3  // ...
4}
5// ...

13.19.3 모듈을 사용하여 거대한 코드 파일 생성 방지하기

  • 정적으로 선언된 종속성과 함께 적절한 크기의 다양한 모듈을 대신 사용하자.
  • 어떤 크기가 올바른 크기인지에 대한 질문은 스타일의 문제이며 팀과 동의해야 한다.
  • 각 기능을 자체 모듈에 넣는 것은 아마도 과잉이지만, 이것, 저것, 그리고 다른 하나를 내보내는 단일 대규모 모듈은 아마도 충분히 모듈화되지 않을 것이다.

13.19.4 CJS, AMD 및 기타 모듈을 ESM으로 변환하기

  • ESM을 사용하여 기존 모듈을 변환하자.

13.19.5 자작으로 만드는 것보다 잘 관리된 번들러를 사용하자

  • 잘 관리되고 커뮤니티가 지원되는 번들러를 사용하자.