📦 JavaScript Module System

(이 외에도 System.js, Require.js 등의 모듈 로더가 있습니다)

ESM의 경우에는 클라이언트 사이드 (브라우저) 에서 사용할 수 있는 모듈 시스템 입니다
CommonJS 는 Node.js 의 모듈 시스템으로 채택되어 활용되고 있습니다
AMD는 require.js 라는 구현체를 활용해 환경에 구애받지 않고 사용할 수 있습니다

물론 CommonJS 를 브라우저에서도 쓸 수 있는 방법이 있고
ESM 또한 Node.js 사용할 수 있는 방법은 있기때문에
환경 종속적으로 딱 잘라 생각할 필요는 없어 보입니다

그럼 각각을 하나씩 살펴보고
어떤 차이점이 있는지도 알아보겠습니다

📦 ES6 Modules(ESM)

ES6 이전까지는, 브라우저 환경에서 사용 가능한 표준 모듈 시스템은 없었습니다
(만약 제가 잘못 알고 있다면 알려주세요!)

이전의 클라이언트 자바스크립트 개발은
필요한 파일(모듈)을 만들어서 같이 배포한 뒤에 <script src="..."> 로 불러오는 방식이었습니다

외부 라이브러리는 공식 배포판을 다운로드 하여 함께 묶어서 배포하거나
<script src="..."> 로 cdnjs, unpkg 에 존재하는 주소를 로드하여 사용했습니다

(그 외에도 많은 방법이 있었겠지요)

<script> 어쩌면 모듈 시스템의 하나라고 할 수 있습니다
그치만...(오니쨩...) 다른 언어처럼 import, include, use 같은게 필요하겠죠

ES6 에서는 드디어 정식으로 모듈 시스템이 도입 되었습니다 🎉

import, export 가 새로 추가된 친구들 입니다
그럼 새로 추가된 친구들은 어떤 역할을 하는지 알아보겠습니다

🚢 export

순서상 import 를 설명하기 이전에 export 문법을 명확히 해야 할 것 같습니다
export 는 기본적으로 named export, default export 두 가지 방법이 존재합니다

named export

선언된 변수명 그대로 export 합니다
named export 는 모듈 내에 여러개 존재할 수 있습니다

named export 는 변수 선언과 동시에 내보내도록 하거나
먼저 정의된 변수들을 모아서 내보내는 방법이 있습니다

// 1. 변수 선언 즉시 내보내기
export let name1;
export const name2;
export var name3;
export function name4 () {/*...*/}
export class MyClass {/*...*/}

// 2. 변수 먼저 정의하고, 모아서 내보내기
const var1;
let var2;
var var3;

export { var1, var2, var3 }

// 3. 먼저 정의된 함수를 별칭으로 변경해서 내보내기
let var4;
export { var4 as var5 } // 다른 모듈에서 import 할 때에는 var5 로 import 해야 함

default export

default export 와 named export 의 차이점은

1. default export 는 모듈에서 하나만 존재할 수 있습니다

2. export default { let, const, var } 와 같은건 안됩니다

   export default expression;
   export default function () {/*...*/} // 익명함수
   export default function myFunction () {/*...*/} // 기명함수
   export default class {/*...*/}
   export default class MyClass {/*...*/}
   export default function* () {/*...*/} // 제너레이터도 동일
   
   // 🙅‍♂️ Uncaught SyntaxError: Unexpected token const
   export default const test = /*...*/ 
   
   // named export 처럼 묶어 내보내기도 가능합니다
   const myModule = {/*...*/}
   const var1 = () => {}
   export { myModule as default, var1 } // as 를 이용해 default export 하였습니다

대략적인 사용방법은 알았으니 호기심이 생깁니다
만약 export default 를 두 번 하면 무슨 일이 생길까요? 에러가 발생합니다!

// 역시나 에러!
Uncaught SyntaxError: Identifier '*default*' has already been declared

잠깐 야크털을 깎아보자면 (야크털 깎기란... 을 알려드리며 또 야크털 깎기)

"*default*" 라는 Identifier는 export 문이 내부적으로 사용합니다
ecma-262 명세는 다음과 같이 설명하고 있습니다

NOTE: "*default*" is used within this specification as a synthetic name for anonymous default export values

(좀 더 궁금하시면 명세를 읽어보세요👍그냥 예약된 식별자로 이해하셔도 좋습니다)

다시 내보내기 (export - from)

export 로 또 한가지 할 수 있는 일이 있습니다
바로 import 와 export 를 한 번에 처리할 수 있는 export - from 입니다!

이 문법은 주로 패키지의 다른 모듈들을 한 데 모아
일관된 형태로 내보내거나 관리하고자 할 때 사용합니다

참고로, 브라우저 환경에서 from 을 사용할 때에는 .js 확장자를 적지 않으면
404 Error 가 발생합니다

// src/utils 패키지는 index.js math.js, logger.js, config.js 모듈을 포함합니다

// 📁 src/utils/math.js
export function add (a, b) {/*...*/}
export function subtract (a, b) {/*...*/}
export function multiply (a, b) {/*...*/}
export function divide (a, b) {/*...*/}

// 📁 src/utils/logger.js
export default {
  print() { /*...*/ }
}

// 📁 src/utils/config.js
export const DB_HOST = 'localhost';
export const DB_USER = 'scott';
export const DB_PASSWORD = 'tiger';

// 📁 src/utils/index.js

// math 모듈에서 일부만 import 한 뒤 다시 export 합니다
export { add, subtract } from './math';

// config 모듈의 모든 export 가능한 변수를 re-export 합니다
export * from './config';

// logger 모듈의 default export 를 Logger 라는 이름으로 변경해 export 합니다
export { default as Logger } from './logger'; 


// 📁 src/index.js

// 디렉토리를 import 하면 기본적으로 index.js 파일을 탐색합니다
import * as utils from './utils';

utils.add(1, 2) // 3
utils.DB_HOST // 'localhost'
utils.Logger.print('TEST') // 'TEST'

조금 길긴 하지만 한 번 쭉 읽어보시면 어떻게 사용하는지 아시겠죠?
이런식으로 패키지의 index 에서 모듈의 내보내는 방식을 다시 한 번 정리하여
하나의 모듈로 내보내는 것을 📦 Barrel 방식 이라고 하기도 합니다 (정식 용어가 아닙니다)

추가적으로 export - from 구문은 import 와 export 를 한번에 처리하는 축약법이지만
export - from 을 처리하는 파일 스코프에 식별자를 바인딩 하지 않습니다

설명이 좀 복잡한것 같아 코드로 예를 들어 보겠습니다

// 📁 src/utils/index.js

// math 모듈에서 일부만 import 한 뒤 다시 export 합니다
export { add, subtract } from './math';

// 근데 내보내기 전에 add 함수를 이 파일에서 사용하고 싶다...? Nope
add(1, 2); // 🙅‍♂️ Uncaught ReferenceError: add is not defined

위 코드의 에러처럼 스코프내에 존재하지 않습니다!

🚢 import

import 는 다른 파일에서 모듈을 불러옵니다
default export 를 불러오거나, named export 를 불러올 수 있습니다

그리고 as 를 이용해 alias 처리
*(asterisk) 를 통해 named export 전체를 불러올 수도 있습니다

아래 예시는 MDN 문서에서 발췌했습니다

import name from "module-name";
import * as name from "module-name";
import { member } from "module-name";
import { member as alias } from "module-name";
import { member1 , member2 } from "module-name";
import { member1 , member2 as alias2 , [...] } from "module-name";
import defaultMember, { member [ , [...] ] } from "module-name";
import defaultMember, * as alias from "module-name";
import defaultMember from "module-name";
import "module-name";

name 과 member, defaultMember 각각의 의미는...

name: import 한 값의 현재 스코프의 이름 (export 하는 쪽의 이름이 아닙니다)
member, memberN: export 된 모듈의 멤버 이름
defaultMember: name 과 동일하게 default export 된 값을 받을 이름
alias, aliasN: 가져온 member 의 새로 주어질 별칭

뭔가 설명이 잘 이해가 안되네요...
각각 나눠서 코드로 예를 들어 볼게요!

먼저 util.js 라는 모듈이 있다고 가정하겠습니다

// 📁 util.js
export function print (msg) {};
export function fetch (url) {};
export default {
  add(a, b) {},
  subtract(a, b) {},
}

기본적인 import 문법

// 📁 app.js

// default export 만 가져옵니다
import util from './util';

util.add(1,2) // 3

// named export 를 가져옵니다
import { print, fetch } from './util';

print('Hello!') // Hello!

as 를 이용해 새 이름 부여하기

// 📁 app.js

import { print as logger } from './util';

logger('Hello!') // Hello!

*(asterisk) 를 이용해 named export 를 모두 불러오기

// 📁 app.js

// util 대신에 다른 이름도 가능합니다
import * as util from './util';

util.print('Hello!') // Hello!

// 😎 그리고 이 코드에는 숨겨진 비밀이 있습니다... 조금 후에 알려드릴게요!

default export, named export 모두 불러오기

// 📁 app.js

import util, { fetch, print } from './util';

util.add(2, 3) // 5
print('Hello!') // Hello!
fetch('https://httpbin.org').then(/*...*/)

어떤 바인딩 없이 모듈 전체의 사이드 이펙트만 가져오기

// 📁 app.js

import 'util';
// util.js 코드가 한 번 실행됩니다. 변수에 바인딩 하지 않았기 때문에 사용할 수는 없습니다

만약 default export 와 named export 를 같이 하는 모듈을 *(asterisk) 로 불러왔다면...?

// 📁 app.js

import * as util from './util';

util.default.add(1, 2) // 3... 아까의 코드의 비밀은 이겁니다.. 이럴수가!

default 라는 프로퍼티가 생겼습니다
그리고 default 프로퍼티는 default export 된 모듈과 같습니다

설명이 길어졌네요... ES6 modules의 export, import 키워드에 대해 알아 보았습니다!
다음은 Node.js 에서 사용 중인 CommonJS 에 대해 알아볼게요!

📦 CommonJS

CommonJS 는 2009년 또 하나의 자바스크립트 표준을 만들기 위한 노력으로 시작되었습니다
처음 CommonJS 를 만들면서 창시자인 Kevin Dangoor 는 다음과 같은 문제를 지적했습니다

CommonJS 그룹이 생각하는 자바스크립트의 지구 정복의 발목을 잡는 것들...

• JavaScript has no module system. To compose JavaScript scripts, they must be either managed in HTML, concatenated, injected, or manually fetched and evaluated. There is no native facility for scope isolation or dependency management.
• JavaScript has no standard library. It has a browser API, dates, and math, but no file system API, much less an IO stream API or primordial types for binary data.
• JavaScript has no standard interfaces for things like Web servers or databases.
• JavaScript has no package management system that manages dependencies and automatically installs them, except JSAN (not to be confused with JSON), which falls short for scope isolation.

간략하게 우리말로 요약하자면...

• 자바스크립트는 모듈 시스템이 없다
• 자바스크립트는 표준 라이브러리가 없다 (브라우저 API, date, math 뿐)
• 웹 서버 또는 데이터베이스등을 위한 표준 인터페이스가 없다
• 자바스크립트는 의존성을 관리하고 설치할 수 있도록 해주는 패키지 관리 시스템이 없다

이와 같은 문제들을 극복하기 위해 시작한 자바스크립트 생태계를 위한 단체입니다

참고로, 두 번째 자바스크립트 표준 라이브러리가 없다는 점에 대해서도
path, fs 등이 Node.js 에서 내장 API 로 제공되도록 CommonJS 그룹의 역할이 있었습니다

그럼 배경은 어느정도 파악했으니, CommonJS 의 모듈 시스템에 대해 알아보겠습니다

ESM 에 핵심 키워드인 import, export 가 있듯이
CommonJS 또한 module.exports, exports, require 세 가지의 핵심 키워드가 있습니다

module.exports

먼저 module 이라는 키워드는 공식 문서에 다음과 같이 정의되어 있습니다

*The module free variable is a reference to the object representing the current module.*
현재 모듈을 나타내는 자유 변수(예약어)라고 하는데요, 빈 객체로 초기화 되어있는 상태입니다

쉽게 얘기하자면, module 이라는 키워드는 현재 모듈에 대한 정보를 담고 있는
일종의 객체(Object) 입니다

기본 문법은 module.exports = expression 으로 작성합니다
자바스크립트에서 식은 곧 값이기 때문에, 값으로 허용되는 어떤 것도 export 할 수 있습니다

// 📁 utils.js

const PI = 3.14;
module.exports.PI = PI;


// 📁 app.js
const utils = require('./utils');
console.log(utils.PI); // 3.14

만약 위와 같이 사용한다면 utils.js 파일의 module 객체는 어떤 상태일까요?

Module {
  ...
  exports: { PI: 3.14 }, // exports 라는 객체 안에 PI 라는 프로퍼티가 생겼습니다
  parent: Module {/*...*/},
  filename: '...',
  loaded: false,
  children: [],
  paths: [ /*...*/ ] 
}

그럼 module.exports.something 처럼 프로퍼티를 만들지 않고
바로 module.exports = 값 으로 내보내면 어떻게 될까요?

// 📁 utils.js

module.exports = 3.14;
console.log(module);

Module {
  ...
  exports: 3.14, // exports 값은 3.14 입니다
  parent: Module {/*...*/},
  filename: '...',
  loaded: false,
  children: [],
  paths: [ /*...*/ ] 
}

당연하지만 module의 exports 프로퍼티의 값이 됩니다

exports

exports 라는 키워드로도 module.exports 와 같은 동작을 수행할 수 있습니다
(조금의 예외가 있습니다. 아래에서 설명할게요)

// 📁 utils.js

exports.PI = 3.14;
console.log(module.exports === exports); // true

console.log(exports); // { PI: 3.14 }

module.exports 는 exports 와 완전히 동일합니다
그렇다는 것은 exports가 module.exports 를 reference 참조 하고 있다는 의미겠죠?

exports 키워드에 대해 Node.js API 문서에는 이런 설명이 있습니다

exports shortcut
The exports variable is available within a module's file-level scope,
and is assigned the value of module.exports before the module is evaluated.

exports 단축 구문
exports 변수는 모듈의 파일 레벨 스코프 안에서 사용 가능합니다
그리고 모듈이 평가되기 전에 (require 되기 전에) module.exports 의 값을 할당 받습니다

위의 설명의 이유로 인해 아래와 같은 결과가 발생합니다

// 📁 utils.js

module.exports = 3.14;
exports.PI = 3.14;

console.log(module.exports); // 3.14 ...?

근데 이건 자바스크립트에서는 당연한 결과가 아닐까요?

exports 가 참조하는건 module.exports 라는 빈 오브젝트였는데
이걸 3.14로 덮어 씌워 버리면
exports 가 참조하던 객체는 저 어딘가로 사라질거에요...

그래서 exports 는 module.exports = expression 과 함께 사용할 수는 없습니다
아래처럼, 프로퍼티를 추가하면 괜찮습니다

export.PI = 3.14;
module.exports.sin = function (a) { /*...*/ }

console.log(module.exports) // { PI: 3.14, sin: function(a) { /*...*/ }

설명이 잘 이해가 안되시면, 저보다 훨씬 잘 정리된 다른 글을 추천합니다

Node.js Module - exports vs module.exports
[NodeJS] module.exports 와 exports 의 차이점
module.exports와 exports 차이 이해하기 - 92Hz | Jongmin's Blog

require

require 는 다른 모듈 파일을 볼러옵니다

모듈을 불러오는 다양한 방법이 존재하는데요
공식 문서에는 대표적으로는 아래 4 가지를 설명하고 있습니다

1. File Modules
2. Folders as Modules
3. node_modules
4. Global Directory

File Modules

상대경로에 있는 파일 중 확장자가 .js, .json, .node 인 파일을 모듈로써 불러옵니다
확장자는 생략할 수 있습니다

// 📁 data.json
{ "data": "Hello World!" }

// 📁 utils.js
module.exports.PI = 3.14;

// 📁 app.js

const data = require('./data');
const utils = require('./utils');

console.log(data); // { data: "Hello World!" }
console.log(utils.PI); // 3.14

Folders as Modules

폴더를 상대 · 절대 경로의 형태(/, ./, ../) 로 require 할 때는
다음과 같은 순서로 탐색합니다

1. package.json 파일에 정의된 name 과 main 의 값을 활용
2. 1번에서 탐색에 실패하면, 해당 폴더에 index.js 또는 index.node 파일이 있는지 확인
3. 모두 실패하면 Cannot find module 에러 throw

근데 사실 1번 설명은 잘 모르겠어요...
혹시 아시는 분이 있으시다면 도와주세요

아무리 공식문서의 설명대로 해보려 해도 잘 안되네요
그래서 모르는건 과감히 설명하지 않겠습니다

2번의 경우는 아래처럼 활용할 수 있습니다

// 📁 ./src/utils/index.js
// utils 폴더 아래에 index.js 파일을 만듦
module.exports.PI = 3.14;

// 📁 ./src/app.js
const utils = require('./utils'); // 자동으로 ./utils/index.js 파일을 탐색합니다
console.log(utils.PI); // 3.14

node_modules

만약 상대, 절대 경로에 대한 표시 없이 (/, ./, ../) require 를 호출하면
Node.js 는 현재 모듈의 최상위 디렉토리에서 시작하여 /node_modules 라는 경로를 앞에 붙이고 탐색합니다

만약 require('bar') 를 호출하면 아래와 같은 순서로 탐색합니다

• /home/doondoony/project/node_modules/bar.js
• /home/doondoony/node_modules/bar.js
• /home/node_modules/bar.js
• /node_modules/bar.js

위 4 가지 탐색 경로는 module.paths 프로퍼티의 값과 같습니다

GLOBAL_DIRECTORIES

Node.js 는 위 3 가지 방법으로 찾지 못하면 OS의 글로벌 파일 경로를 탐색합니다

Node.js 는 기본적으로 다음 GLOBAL_DIRECTORIES 를 탐색합니다

• $HOME/.node_modules
• $HOME/.node_libraries
• $PREFIX/lib/node

$PREFIX 의 경우는 Node.js 가 설정한 node_prefix 경로입니다
npm 으로 패키지 매니징을 하고 계신다면 위와 같은 곳까지 탐색될 일은 없겠죠?

🐝 AMD

암드 그거 CPU 아닌가요? 아 암드 아시는구나~ 와! 라이젠! 와 가성비!

아니구요 AMD(Asynchronous Module Definition) 의 약자입니다
AMD는 다음과 같은 목표를 충족하기 위해 CommonJS 독립한 그룹입니다

The Asynchronous Module Definition (AMD) API specifies a mechanism
for defining modules such that the module and its dependencies can be asynchronously loaded.

AMD API 는 모듈과 종속성 파일들을 비동기적으로 로드할 수 있도록 모듈을 정의하는 매커니즘입니다.

CommonJS, ESM 모두 동기식 로딩 방식을 채택하고 있습니다
따라서 로드한 모듈이 아직 사용되지 않았음에도, 미리 로딩해야 합니다

AMD 는 동적 로딩을 가능하게 하고, 의존성 관리나 모듈화를 할 수 있는 API를 제공합니다

다른 모듈 시스템도 의존성 관리와 모듈화는 모두 지원하기 때문에
동적 로딩에서 차별점이 있다고 할 수 있죠

AMD 에 대해 조사하면서 느낀 개인적인 생각은 2018년 현재도 유효한가? 입니다

먼저 클라이언트 사이드 자바스크립트에서는...

1. ES6 등장과 함께 드디어 브라우저에서도 사용 가능한 ESM 내장 모듈 시스템 등장(!)
   (물론 하위 호환성 덕분에 트랜스파일러가 필요하지만...)
2. webpack 과 같은 모듈 번들러의 비동기 모듈 로딩 처리
3. 동적 로딩 또한 내장 메서드 import() 로 구현되어 proposal stage3 단계 입니다

Node.js 쪽은 어떨까요

1. CommonJS 라는 친구가 굳건하게 버티고 있고
2. 심지어 최신 Node.js 는 ESM 을 표준으로 도입하기 위해 실험적인 기능도 제공합니다 (.mjs)

그래서! 그냥 어떻게 쓰는지 정도만 살펴보겠습니다
(절대 귀찮아서 아님 아무튼 아님)

// 📁 index.html

<!DOCTYPE html>
  <html lang="en">
    <head>
    <!-- head에 들어갈 어떤것들 -->
      </head>
<body>
      <!-- AMD 구현체인 require.js 로딩 -->
        <script src="https://cdnjs.cloudflare.com/ajax/libs/require.js/2.3.6/require.js"></script>
<!-- 우리의 스크립트 파일 로딩 -->
  <script src="./index.js"></script>
</body>
</html>

// 📁 utils.js

// require.js 는 define 안의 callback 스타일로 모듈을 정의하여 내보냅니다
define(function() {
  return {
    add(a, b) {
      return a + b;
    },
    subtract(a, b) {
      return a - b;
    }
  };
});

// 📁 app.js

// require 함수의 첫번째 인자는 불러올 모듈, 두번째 인자는 함수로 인자는 물러온 모듈의 이름 입니다
require(["./utils"], function(utils) {
  const result = utils.add(1, 2);
  console.log('결과: ', result);
});

// 결과: 3

AMD 와 require.js 에 대한 일천한 경험으로 인해
다음 좋은 글을 참고하심이 좋겠습니다

[RequireJS] RequireJS 사용 방법 정리
RequireJS - AMD의 이해와 개발
Learn X in Y minutes

🌑 마치며

자바스크립트의 모듈 시스템에 대해 알아보았습니다

저는 프론트엔드 개발을 시작한지 얼마 되지 않았습니다
그래서 모듈 시스템이 표준으로 도입된지 얼마 되지 않았다는 사실에 적잖이 놀랐습니다... 😲
뭔가 좋은 시절에 개발하고 있구나 라는 생각도 들었구요!

다음 글은 모듈 시스템도 배웠겠다
Module Pattern 과 Module Pattern 을 적용하여 실제로 npm 에 패키지를 배포해볼까 합니다

긴 글 읽어주셔서 항상 감사합니다
오타나 잘못된 정보에 대한 제보는 항상 환영합니다 🎊

📖 References

다음의 링크들을 글을 쓸 때 참고하였습니다

Module

• 16. Modules
• Modules vs. Libraries vs. Artifacts: Whats the difference?
• Understanding : javascript-modules
• What are "routines" in programming?
• 모듈 - 프로그래밍 언어들
• What is a Module? - Definition from Techopedia
• What is Module? Webopedia Definition

ES6 Modules(ESM)

• Understanding ES6 Modules
• ES6 In Depth: Modules - Mozilla Hacks - the Web developer blog
• ES6 In Depth: 모듈 ★ Mozilla 웹 기술 블로그
• import
• export
• ECMAScript® 2018 Language Specification
• ES6 Modules
• Module | PoiemaWeb
• Introduction to ES Modules
• Using JavaScript modules on the web | Web Fundamentals | Google Developers
• Module specifiers: what's new with ES modules?
• The state of JavaScript modules - webpack - Medium
• nhnent/fe.javascript

CommonJS

• r/node - I am Ryan Dahl, creator of Node.js, AMA.
• CommonJS - Wikipedia
• NAVER D2
• Using ES modules natively in Node.js
• CommonJS effort sets JavaScript on path for world domination

AMD

• How to get started with RequireJS
• [RequireJS] RequireJS 사용 방법 정리
• Moving Past RequireJS
• NAVER D2
• amdjs/amdjs-api
• NAVER D2
• It's Not Hard: Making Your Library Support AMD and CommonJS
• AMD is Not the Answer
• 자바스크립트 모듈 제공을 위한 AMD, CommonJS 그리고 RequireJS 소개
• Node.js(CommonJS module specification) and require.js(AMD- asynchronous module definition)
• tc39/proposal-dynamic-import
• Dynamic import() | Web | Google Developers
• 2017년과 이후 JavaScript의 동향 - JavaScript(ECMAScript)