삶도 재입학이 되나요?

모듈 번들러란?
쉽게 말해 여러 모듈(파일)들을 하나의(또는 몇 개의) 번들 파일로 묶어주는 도구다
번들러는 모듈의 의존 관계를 분석하여 브라우저가 인식할 수 있는 자바스크립트 코드로 변환한다
예를들어 아래와 같은 js 파일이 있다고 가정하면
모듈 번들러는 브라우저가 인식할 수 있도록 다음 함수로 변환한다.
그리고 변환된 모듈 함수들이 모듈 간에 서로 참조할 수 있도록 하나의 파일로 합쳐지게 된다
간단 내부 동작
1. 소스 코드를 모듈 객체로 변환하기 (AST로 파싱)
모듈 번들러는 엔트리부터 소스 코드를 모듈로 차례대로 변환 큐(queue)에 넣고 변환시킨다
변환을 어떻게 진행하냐면 소스 파일을 AST(Abstract Syntax Tree)로 파싱하는 것
즉, 엔트리 기준으로 모듈 간 의존 관계를 파악하기 위해 트리 구조로 만드는 것이다
2. AST 순회
AST를 순회하는 과정에서 import를 수집하는데, 의존성 맵을 만들기 위함이다
import 선언을 만나면 해당 경로를 실제 파일 경로로 resolve한다. 
그리고 "import 문자열" -> "모듈 ID" 형태로 deps 맵에 저장
source.forEachChild(node => {
  if (node.kind === ts.SyntaxKind.ImportDeclaration) {
    let importDecl = node as js.ImportDeclaration;
    // module specifier should be a string literal
    let moduleSpecifier = importDecl.moduleSpecifier.getText(source);
    let dep = JSON.parse(moduleSpecifier) as string;
    ...
    queue.push(depPath);
    deps.set(dep, depID);
  }
});
3. 트랜스파일링
의존 관계 분석까지 마쳤으면 CommonJS로 트랜스파일하면 변환 단계는 끝
let transpiled = js.transpileModule(content, {
    compilerOptions: {
      module: js.ModuleKind.CommonJS,
      ...
    }
  }).outputText;
4. 코드 생성 및 번들링
변환 단계에서 만든 모듈 객체들을 합쳐 번들 파일을 만들어야 한다.
var modules = {
  0: [ // ← 모듈 ID
    function(require, module, exports) {
      ... // ← 트랜스파일 된 코드
    },
    {
      "otherModule": 1, // ← 의존성 맵
      ...
    }
  ],
  1: ...
}
그리고 생성된 모듈 코드를 실행할 실행 함수가 필요하다.
함수를 실행하면 module.exports에 모듈이 익스포트한 값이 들어간다. 그 값을 그대로 반환하면 된다.
function executeModule(id) {
  var mod = modules[id];
  var localRequire = function(path) {
    return executeModule(mod[1][path]); // path를 id로 바꿔 실행
  };
  var module = { exports: {} };
  mod[0](localRequire, module, module.exports);
  return module.exports;
}
여기서 번들러 런타임의 핵심을 알 수 있다.
모듈 함수에 (require, module, exports)를 주입하고
require는 “문자열 경로”를 deps 맵으로 “정수 id”로 바꿔서
해당 모듈을 실행하고 exports를 돌려준다
이로써 번들러가 동작하는 간략한 과정이다. 이제 실제로 만들어보쟈
번들러 만들기
1. 예제
index.js
목표는 이러하다. index.js에서 add3.js와 add5.js를 가져와서 사용할 것이다. 
add5.js
또한, add3.js와 add5.js에서도 index.js파일에 선언된 NUMBER_TO_ADD라는 값을 가져올 것이다.
즉, 서로 다른 파일을 하나의 모듈로 만들어야 한다. 그러기 위해서는 번들러가 필요하다!
번들러를 만드는 과정은 크게 2개로 나눌 수 있다.
1. Dependency Resolution
즉, 소스 코드를 읽고, 파싱(AST로)하고 import를 찾아 의존성 그래프를 만드는 단계
2. Bundling
그래프에 있는 모듈을 모아서 module map과 runtime(require)의 형태로 한 파일(bundle.js)로 만드는 단계
index.js를 엔트리로 ESModule 문법을 사용하여 다른 파일을 가져올 것이다. 
먼저, index.js에서 import를 읽고 두 파일(add함수 파일들)을 따라가며 그래프 생성한다.
그리고 최종 산출물을 브라우저/Node에서 돌아가도록 (여기서는 Node) CommonJS 스타일로 바꾸고, runtime으로 실행하면 끝!
2. 빌드 (entry → graph → bundle → write)
빌드 함수를 만들자. 빌드 함수는 크게 세 가지 일을 한다.
먼저 createDependencyGraph에서 의존성 그래프를 생성하고
그래프를 바탕으로 bundle에서 출력 파일을 만든다
마지막으로 출력 파일을 순회하면서 메모리 상에 있는 번들 코드를 실제 디스크에 저장하면 된다.
3. 의존 그래프 만들기
의존성 그래프를 만들기 위해서 우리는 모듈 객체가 필요하다. 
모듈 객체는 filePath, content, ast, dependencies(import 대상 모듈들) 등의 정보를 가지고 있다. 모듈 객체를 만들고 Resolving 함수까지 만들어보자
Module을 구성하는 정보는 다음과 같다.
filePath
content (원본 코드)
ast (파싱된 결과, babel로 파싱함)
dependencies (import 대상 모듈들)
이제 이 모듈 객체의 AST에서 ImportDeclaration 노드만 찾아 내야 한다. 
AST 내부를 바벨 변환기를 통해 살짝 살펴보면 import문이 어디에 있는지 알 수 있다.
하지만 아직 끝이 아니다. import 경로는 두 종류가 가능하기 때문이다.
상대 경로인 ./foo/bar가 있고 패키지를 호출하는 lodash가 있을 수 있다. 일단 지금 예제에서는 상대경로만 다루기로 하자. 
그럼 import 된 파일의 상대경로만 보고 파일이 어디에 위치했는지 어떻게 알 수 있을까?
4. 리졸빙(resolving)
상대경로를 찾기 위해 baseUrl에 상대경로를 합쳐서 새로운 url를 만들면 된다.(생각해보니 리액트 서버 컴포넌트도 위와 동일한 방식으로 상대경로 탐색을 한다)
위 리졸버는 Node.js처럼 확장자 추가나 package.json 처리, 디렉토리 인덱스를 하지 않는 간단한 버전이다. 실제 번들러에서 리졸버는 단순 경로 결합만 한다.
이제 만들어놓은 resolveRequest로 변경하고. createModule을 호출하여 재귀적으로 의존성 그래프를 만든다. 
그럼 모듈 객체는 아래와 같이 나온다. 
Module {
  filePath: '/test/fixture/index.js',
  content:
   'import add3 from './add3.js';\nimport add5 from './add5.js';\n\nconsole.log('add3(2): ', add3(2));\nconsole.log('add5(2)', add5(2));\n',
  ast:
   Node { /*...*/ },
  dependencies:
   [ Module {
       filePath: '/test/fixture/add5.js',
       content:
        'function add5(side) {\n  return side * side;\n}\nexport default add5;\n',
       ast: Node {/* ... */},
       dependencies: []
      },
     Module {
       filePath: '/test/fixture/add3.js',
       content:
         'function add3(n) {\n  return side * side;\n}\nexport default add3;\n',
       ast: Node {/* ... */},
       dependencies: []
      }
   ]
}
앞으로 우리는 위 모듈 객체를 기반으로 아래와 같은 최종 번들 파일로 만들 것이다.
const modules = {
  'add3.js': function(exports, require) {
    exports.default = function add3(n) {
      return n + 3
    };
  },
  'add5.js': function(exports, require) {
    exports.default = function add5(n) {
      return n + 5
    };
  },
  'index.js': function(exports, require) {
    const MAGIC_NUMBER = 2;
    const adde = require('adde.js').default;
    const add5 = require('add5.js').default;
    console.log("add3(2): ", add3(MAGIC_NUMBER));
    console.log("add5(5)", add5(MAGIC_NUMBER));
  },
};
webpackStart({
  modules,
  entry: 'index.js',
});
이제 1단계인 Dependency Resolution 단계가 끝났다. 이제 outputFiles을 만들기 위한 2단계인 본격적인 번들을 해보자!
번들 단계도 다음과 같이 3개의 단계로 구성된다.
모듈을 파일로 그룹화
모듈 맵 생성과 모듈 스코프 생성
런타임 코드 생성
그럼 모듈을 파일로 그룹화 먼저 살펴보자
5. 모듈 그룹화
이 단계에서는 의존성 그래프에 있는 모든 모듈을 어떤 출력 파일에 넣을지 결정한다.
실제 Webpack 같은 번들러는 여기서 코드 스플리팅을 하는데, 코드 스프리팅은 다음과 같이 진행된다.
정적 import → 같은 청크
동적 import → 별도 청크 (lazy loading)
공통 모듈 → 별도 vendor 청크 (최적화)
하지만 이 예제에서는 코드 스프리팅은 제외하고 모든 모듈을 하나의 파일로 묶는다! 
그래서 일단 그래프에 있는 모든 모듈을 순서에 상관없이 일단 수집하면 된다. 즉, 의존성 그래프를 순회하여 배열로 만드는 과정이다.
build 함수에서 실행된 bundle 함수는 그래프를 DFS로 순회하며 루트 모듈부터 의존성을 따라 모든 모듈을 배열에 추가한다.
6. 모듈 맵 생성 & 팩토리 함수 래핑
이제 모듈 맵을 생성해야 하는데, 왜 객체 형태의 모듈 맵을 생성해야 할까.
바로 런타임의 때 번들 파일 안에서 require('add3.js')를 호출할 때, 모듈을 실행해야 할지 빠르게 찾아야 하기 때문이다.
const require = (moduleName) => {
  const factory = modules[moduleName]; 
  // ...
};
이렇게 모듈 맵은 런타임에서 모듈을 이름으로 즉시 찾기 위해 맵으로 만들어지는 것!
키는 파일 경로, 값은 모듈 콘텐츠를 팩토리 함수로 감싼 형태이다. 함수 실행 시 새로운 실행 컨텍스트가 생성되어, var, let, const, 함수 선언 등이 외부로 노출되지 않아 모듈이 격리된다.
팩토리 함수는 exports와 require를 인자로 제공하고, import/export를 CommonJS 스타일로 변환한다. 이제 마지막으로 런타임 코드를 작성하면 된다. 
7. 런타임 생성
런타임은 번들 파일에 포함되는 실행 코드로, 모듈을 연결한다. 여기서 핵심은 moduleCache로 순환 의존성을 방지하는 것이다! 그럼 코드로 살펴보자
addRuntime은 최종 산출물을 반환해야 한다.
여기서 webpackStart는 애플리케이션은의 시작점과도 같다.  moduleMap과 entry를 받아 require 함수를 정의한다.
캐시에 있는 모듈을 모듈 이름으로 읽어오는 식이다. 
이렇게 모듈 캐시와 require 함수 정의하고 빌드 함수를 실행하면 끝!!
이제 제대로 번들러가 작동하는지 확인해보자
output에 산출물이 잘 나오는 것을 확인했다! 이제 output 파일을 실행시켜보면
오 마이 갓! 나의 첫 번들러가 작동했다
8. 문제
엔트리인 index.js와 의존 파일들은 서로 import를 하고 있다. 앞서 말했던 순환 의존성이 발생할 수 있는데, 순환 의존성 관련해서 트러블 슈팅을 해보자
현재 번들러는 아래와 같이 참조하고 있다
index.js → add3.js를 import
add3.js → index.js에서 NUMBER_TO_ADD를 import
결과: A → B → A 형태의 순환 의존성 발생
번들러를 돌려보면 오버플로우가 나온 것을 확인할 수 있다. 현재 코드에서 재귀를 도는 곳은 2곳이 있다.
의존성 그래프 생성 단계 
createModule → initDependencies →  createModule...
번들링 시 모듈 수집 단계 
collectModules 재귀 호출
위 두 재귀에서 중복 참조를 막는 코드를 넣어주면 된다.
그리고
Map과 Set으로 각각 중복을 방지하고 다시 번들러를 돌리면
잘 동작한다!
참고
https://lihautan.com/building-a-simplified-webpack-clone
https://engineering.linecorp.com/ko/blog/write-you-a-webpack-for-great-good
https://www.youtube.com/watch?v=UNMkLHzofQI
https://www.youtube.com/watch?v=Gc9-7PBqOC8&list=PLBh0sgvxjos26ryAmD9cYCAvP8pRZCEl2

모듈 번들러 만들기 (1)

댓글