Table of Contents

require()를 정적 import라고 설명한 제안
일곱 가지 경우를 담은 입력
webpack: stats와 산출물에 남는 정보
Turbopack: 분석 파일에서 빠진 구분이 모듈 호출에 남는다
Vite: 형식 호환 처리가 남기는 단서
- getModuleInfo는 import와 require()를 한 목록에 담는다
- 산출물의 도우미 함수가 알려 주는 범위
coldpath에서 고친 것
- 소스를 읽어 간선의 종류와 위치를 고치기
- 간선을 고친 뒤 제안이 바뀐 과정
import와 require()의 차이가 남는 곳

`require()`를 정적 import라고 설명한 제안

coldpath 0.6.0으로 Turbopack 빌드를 분석하다가 이상한 제안을 발견했다. require()로 가져온 모듈에 "정적 import 체인이 닿는다"는 설명이 붙어 있었다. 아래는 이 문제를 재현한 페이지다. ESM 모듈은 정적 import로, CommonJS 모듈은 require()로 가져오고, 두 모듈의 계산 함수는 각각 버튼을 눌러야 실행된다.

import {useState} from 'react'
import {esmHeavy} from '../../src/heavy-esm.js'
const cjsHeavy = require('../../src/heavy-cjs.js')

export default function Page() {
  const [text, setText] = useState('ready')
  return (
    <main>
      <button id="esm" onClick={() => setText(esmHeavy())}>esm</button>
      <button id="cjs" onClick={() => setText(cjsHeavy.compute())}>cjs</button>
      <p id="out">{text}</p>
    </main>
  )
}

첫 진입과 CommonJS 버튼 클릭의 실행 기록을 각각 수집해 분석하자 heavy-cjs.js에 다음 제안이 붙었다. 출력에서 제안의 종류와 설명만 옮겼다.

{
  "kind": "split-review",
  "explanation": "A static import chain reaches this source, and part of it executes initially. Consider separating the later-only functionality before introducing import(); deferring the whole module may break initial behavior."
}

페이지에서 heavy-cjs.js를 가져오는 코드는 3번 줄의 require()다. 그런데 coldpath는 이 의존성을 그래프에 정적 import로 기록했고, 그 분류를 바탕으로 설명을 만들었다. 소스의 구문과 분석 결과가 어긋난 이유부터 찾아야 했다.

이 차이가 어디서 사라지는지 확인하려면 번들러가 내보낸 기록과 산출물을 함께 봐야 했다. 소스맵 없이 토스증권의 JavaScript를 추적한 글에서는 coldpath의 복원 그래프를 설명하며 이렇게 적었다.

webpack의 생성 코드에서는 정적 import와 require()가 같은 호출이 되므로 대부분 unknown이다.

토스증권의 청크는 Next.js가 쓰는 webpackChunk_N_E 전역에 등록돼 있었고, 당시 살펴본 모듈 호출에는 이 설명이 맞았다. 그런데 같은 입력을 여러 번들러로 빌드해 보니 호출 자체가 최적화로 사라지기도 했고, Turbopack처럼 분석 파일에 없는 구분이 런타임 호출에는 남기도 했다. 처음 발견한 설명의 오류도 Turbopack의 분석 파일에 기록된 동기 의존성을 모두 정적 import로 해석한 데서 생겼다.

다만 지연 로딩을 제안할 때 필요한 것은 구문의 이름보다 그 구문이 대상 모듈을 언제 실행하는지였다. 모듈 본문에서 바로 부른 require()는 import와 같은 시점에 대상 모듈을 실행하고, 함수 안에서 부른 require()는 그 함수가 불릴 때 실행한다. 그 시점을 알아내려면 먼저 구문의 종류와 위치를 알아야 했다.

이번에는 번들러가 import와 require()의 차이를 어디에 남기는지 살펴봤다. webpack의 stats, Turbopack의 분석 파일, Vite 플러그인의 모듈 정보, esbuild의 metafile을 브라우저가 받는 산출물과 비교했다. 여기서 원래 구문을 어디까지 알아낼 수 있는지 확인하고, 그 결과를 바탕으로 coldpath의 분류를 고친 뒤 제안이 어떻게 바뀌는지 버전별로 따라갔다.

기본 실험은 2026년 10월 4일, macOS(arm64)와 Node.js 24.20.0에서 진행했다. 번들러 버전은 webpack v5.111.1, Next.js v16.3.8(Turbopack, 내장 webpack 5.98.0), Vite 8.3.2와 그 빌드를 맡는 Rolldown v1.2.12, esbuild v0.28.2로 고정했다.

coldpath는 npm 배포본을 썼다. 10월 8일에, 10월 4일 수집한 실행 기록과 분석 파일을 0.6.0, 0.6.1, 0.8.0, 0.8.1, 0.8.2로 각각 다시 분석해 버전별 결과를 비교했다. Vite의 부수 효과 import 반례는 10월 5일에 확인했다. 실험 코드와 측정값은 yceffort/blog-experiments 저장소의 bundler-import-memory에 있다.

이 글에서 자주 쓰는 용어는 다음 뜻으로 쓴다.

간선: 의존성 그래프에서 한 모듈이 다른 모듈을 가져오는 연결 하나다. entry.js가 esm-dep.js를 가져오면 entry.js -> esm-dep.js가 간선 하나이고, 그 연결을 만든 구문(정적 import, require(), 동적 import())을 간선의 종류라고 부른다.
정적 import 체인: 진입점에서 어떤 모듈까지 정적 import 간선만으로 이어진 경로다.
복원 그래프: 번들러의 그래프 정보 없이 산출물의 모듈 호출만 읽어 다시 만든 의존성 그래프다. coldpath의 modules --graph가 만든다.
지정자: './cjs-dep.js'처럼 import나 require()에 넘기는 경로 문자열(specifier)이다.
최상위: 함수 안이 아니라 모듈 본문에서 바로 실행되는 위치다. 최상위 require()는 그 모듈이 실행될 때 함께 실행된다.
모듈 함수: 번들러가 모듈 하나의 코드를 감싸 만든 함수다. webpack과 Turbopack 산출물은 이 함수를 id로 찾아 실행한다.

일곱 가지 경우를 담은 입력

비교에 쓴 입력은 아래 entry.js 하나다. import와 require()로 ESM과 CommonJS를 가져오는 경우를 넣고, 부수 효과 import와 쓰지 않는 import, 동적 import도 추가했다. 각 의존 모듈에는 'M_ESM_DEP' 같은 고유한 문자열을 넣어 산출물에서도 찾을 수 있게 했다.

import {esmDep} from './esm-dep.js'
import cjsDefault from './cjs-default.js'
import './side-effect.js'
import {unusedDep} from './unused-dep.js'
const {cjsDep} = require('./cjs-dep.js')
const {esmRequired} = require('./esm-required.js')

export function run() {
  return [esmDep(), cjsDefault(), cjsDep(), esmRequired(), globalThis.M_SIDE_EFFECT, () => import('./lazy-dep.js').then((m) => m.lazyDep())]
}

줄	경우	가져오는 모듈의 형식
1	ESM에서 import	ESM
2	ESM에서 default import	CommonJS(`module.exports = function`)
3	부수 효과만 있는 import	전역 변수에 값을 쓰는 스크립트
4	import했지만 쓰지 않음	ESM
5	`require()`	CommonJS
6	`require()`	ESM
9	동적 `import()`	ESM

package.json에는 type 필드를 두지 않았고, "sideEffects": ["./src/side-effect.js"]로 부수 효과가 있는 파일을 하나만 선언했다. 번들러에 넘긴 진입점 src/index.js는 run()을 호출해 결과를 전역 변수에 담기만 한다. Next.js 빌드에서는 pages/index.jsx에서 run()을 호출해 그 결과를 화면에 표시한다.

그래프 정보는 아래 방법으로 읽었다. 프로덕션 산출물은 코드를 축소한 버전과 축소하지 않은 버전으로 만들었고, Next.js 내장 webpack만 축소본으로 비교했다.

번들러	그래프 정보	얻는 방법
webpack 5.111.1	stats JSON의 `modules[].reasons`	`stats.toJson({reasons: true, orphanModules: true, ...})`
Turbopack(Next.js 16.3.8)	`.next/diagnostics/analyze/data/modules.data`	`next experimental-analyze --output`
Vite 8.3.2(Rolldown)	플러그인 훅의 `this.getModuleInfo(id)`	`generateBundle` 훅에서 모든 모듈을 조회
esbuild 0.28.2	metafile의 `inputs[].imports`	`metafile: true`

webpack: stats와 산출물에 남는 정보

stats의 reason에 남는 것

webpack stats의 reasons에는 해당 모듈을 가져오는 모듈과 의존성의 종류가 기록된다. 아래는 모듈 연결(module concatenation, 여러 모듈을 한 함수 범위로 합치는 최적화)을 끈 빌드(optimization.concatenateModules: false)에서 entry.js와 연결된 reason만 모은 것이다. 모듈 연결을 켠 기본 빌드와의 차이는 뒤에서 다룬다.

./src/esm-dep.js       harmony side effect evaluation  1:0-35    inactive
                       harmony import specifier        9:10-16
./src/cjs-default.js   harmony side effect evaluation  2:0-41    inactive
                       harmony import specifier        9:20-30
./src/side-effect.js   harmony side effect evaluation  3:0-25
./src/unused-dep.js    harmony side effect evaluation  4:0-41    inactive, orphan
./src/cjs-dep.js       cjs require                     5:17-40
./src/esm-required.js  cjs require                     6:22-50
./src/lazy-dep.js      import()                        9:91-114

import는 harmony로 시작하는 문자열로, require()는 cjs require로 남고, 모든 reason에 줄:열-열 위치가 붙는다. 이 문자열은 의존성 클래스마다 정의된 type 게터에서 온다. stats를 만들 때는 그 값을 그대로 옮겨 적는다.¹

// lib/dependencies/HarmonyImportSideEffectDependency.js
get type() {
  return "harmony side effect evaluation";
}

// lib/dependencies/CommonJsRequireDependency.js
get type() {
  return "cjs require";
}

1번 줄의 import 문에는 reason이 두 개 붙어 있다. harmony side effect evaluation은 import 선언의 위치(1:0-35), harmony import specifier는 가져온 이름을 실제로 쓰는 위치(9:10-16)를 가리킨다. sideEffects로 부수 효과가 없다고 선언된 모듈은 선언 위치의 reason이 inactive가 되고 사용 위치만 활성으로 남는다.

쓰지 않아서 번들에서 빠진 unused-dep.js도 orphan 모듈(어느 청크에도 들어가지 않은 모듈)로 stats에 남아 있다. stats에서는 산출물에 포함되지 않은 import까지 확인할 수 있다. 다만 orphan 표시만으로 번들에서 빠졌다고 판단할 수는 없다. 모듈 연결을 켠 기본 빌드에서는 진입점에 합쳐진 entry.js, esm-dep.js, esm-required.js도 orphan으로 표시됐다.

산출물의 모듈 호출은 같아질 수 있다

같은 페이지를 Next.js 16.3.8의 webpack 모드로 빌드하면 페이지 모듈의 앞부분이 이렇게 된다. Next.js에 내장된 webpack은 5.98.0이다.

var E=n(72),t=n(5138),r=n.n(t);n(2199);let{cjsDep:s}=n(8030),{esmRequired:u}=n(4979);

n은 모듈 함수의 세 번째 인자로 들어오는 __webpack_require__를 축소한 이름이다. n(5138)은 2번 줄의 default import, n(2199)는 3번 줄의 부수 효과 import, n(8030)과 n(4979)는 5번과 6번 줄의 require()다. 1번 줄의 esm-dep.js는 페이지 모듈에 합쳐졌고, 함수 호출도 최적화로 사라져 "M_ESM_DEP"라는 문자열만 남았다.

stats에서 harmony와 cjs require로 구분되던 의존성이 산출물에서는 모두 n(id)라는 같은 모양의 호출이 됐다. 이 예제에서 default import의 흔적은 뒤에 붙은 n.n(t)에 남아 있다. CommonJS 모듈의 module.exports를 default로 꺼내는 호환 함수다.

두 구문이 같은 호출이 되는 과정은 webpack 5.111.1의 소스에서 확인했다. Next.js에 내장된 5.98.0의 소스까지 확인한 것은 아니다. import 문은 RuntimeTemplate.importStatement에서 전체를 새로 만든다.²

importContent = `/* harmony import */ ${optDeclaration}${importVar} = ${RuntimeGlobals.require}(${moduleId});\n`;

require()는 원래 코드를 부분적으로 치환한다. CommonJsRequireDependency가 인자 자리를 모듈 id로 바꾸고, 함께 등록되는 RequireHeaderDependency가 require라는 이름을 __webpack_require__로 바꾼다.³

// lib/dependencies/CommonJsRequireDependency.js
const content = runtimeTemplate.moduleId({
  module: importedModule,
  chunkGraph,
  request: dep.request,
  weak: dep.weak
});
source.replace(dep.range[0], dep.range[1] - 1, content);

// lib/dependencies/RequireHeaderDependency.js
runtimeRequirements.add(RuntimeGlobals.require);
source.replace(dep.range[0], dep.range[1] - 1, RuntimeGlobals.require);

하나는 문장을 새로 쓰고 다른 하나는 기존 호출을 고쳐 쓰는데, 결과 문자열은 둘 다 __webpack_require__(id)가 된다. 지난 글에서 coldpath의 복원 그래프 간선이 대부분 unknown이었던 이유가 여기에 있다.

동적 import의 모양도 달랐다. Next.js 내장 webpack 산출물에서는 n.e(990).then(n.bind(n,6990))였고, coldpath 0.6.0은 이 bind 형태만 동적 간선으로 인식했다. webpack 5.111.1을 단독으로 쓰면 같은 코드가 r.e(132).then(()=>r(132))가 된다. 대상 환경이 화살표 함수를 지원하면 bind 대신 화살표 함수를 쓰기 때문이다.⁴ coldpath 0.6.0은 이 r(132)를 평범한 호출로 보고 unknown으로 분류했다.

수정한 복원 로직은 n.e(chunk)나 청크 로드 호출만 담은 Promise.all([n.e(a), ...]) 뒤의 .then에 넘긴 화살표 함수도 동적 간선으로 인식한다. 다만 Promise.resolve().then(() => n(id))는 unknown으로 남긴다. 새 청크를 받지 않는 import()와 사용자가 작성한 Promise.resolve().then(() => require(...))가 같은 모양이 될 수 있기 때문이다. 수정 커밋 90b7baa에 이 구분과 검증 사례가 있다.

모듈 연결이 CommonJS로 확장된 뒤

모듈 연결이 적용되면 비교할 호출 자체가 사라질 수도 있다. 5.109.0(2026년 7월 23일)부터 정적으로 분석할 수 있는 CommonJS 모듈도 모듈 연결 대상이 됐고, 5.110.0(2026년 8월 27일)부터는 합친 모듈을 __webpack_require__.cw라는 지연 접근자로 감싸고 require()를 그 자리에 인라인한다.⁵ 같은 입력을 5.111.1 기본 설정으로 빌드한 결과는 이렇다.

var t=r.cw(function(t,e){function o(){return"M_ESM_REQUIRED"}r.d(e,{esmRequired:()=>o})}),e=r(678),o=r.n(e);r(19);const{cjsDep:n}=r(234),{esmRequired:s}=t();

require()로 가져온 ESM 모듈(esm-required.js)은 r.cw(...)로 감싸져 entry 안에 합쳐졌고, 원래 require()가 있던 자리에서 t()로 호출된다. CommonJS 파일 세 개는 여전히 r(678), r(19), r(234)로 남았는데, stats의 optimizationBailout을 보면 이유가 ModuleConcatenation bailout: Module is not in strict mode다. 이 세 파일 맨 앞에 'use strict'만 붙여 다시 빌드하면 stats에는 orphan을 빼고 ./src/index.js + 6 modules 하나와 동적으로 불러오는 lazy-dep.js만 남는다. 축소하지 않은 산출물에서 cjs-dep.js 부분은 다음과 같다.

// MODULE: ./src/cjs-dep.js
var cjs_dep_namespaceFn = /*#__PURE__*/__webpack_require__.cw(function(module, exports) {

module.exports = {
  cjsDep() {
    return 'M_CJS_DEP'
  },
}

});

// (중략)
const {cjsDep: entry_cjsDep} = (cjs_dep_namespaceFn())

이 빌드에서 __webpack_require__(id) 형태로 남은 호출은 동적 import의 r(132) 하나뿐이다. 2번 줄의 default import는 __webpack_require__.n(cjs_default_namespaceFn())로, 5번 줄의 require()는 cjs_dep_namespaceFn()로 남는다. 이 두 사례에서는 호환 함수가 단서가 되지만, 그 단서는 앞서 본 5.98.0의 n.n(t)에도 있었다.

CommonJS도 모듈 연결 대상이 되면서 산출물에서 모듈 경계와 호출이 사라지는 경우가 늘었다. ESM에서는 이전 버전에도 있던 최적화이고, 최신 버전에서도 연결 대상에서 빠진 모듈은 __webpack_require__(id)로 남는다. 결국 호출 모양으로 원래 구문을 알아낼 수 있는지는 버전만으로 정할 수 없다. 산출물에 어떤 호출이 남았고, 거기에 호환 처리가 붙어 있는지를 함께 봐야 한다.

`"type": "module"` 패키지 안의 `require()`

같은 입력을 "type": "module"인 패키지에 넣고, CommonJS 파일 두 개만 .cjs로 바꿔 다시 빌드했다. 이번에는 entry.js가 ESM으로 판정되므로, 그 안의 require()를 번들러가 어떻게 처리하는지 볼 수 있다.

webpack 5.111.1은 에러 0건, 경고 0건으로 빌드를 마쳤다. 그런데 산출물에는 require('./cjs-dep.cjs')와 require('./esm-required.js')가 원래 코드 그대로 남아 있었고, stats 그래프에서는 두 모듈이 아예 빠져 있었다. require가 없는 환경(Node.js의 vm 컨텍스트)에서 이 산출물을 실행하면 ReferenceError: require is not defined가 난다.

원인은 webpack의 기본 규칙에 있다. "type": "module"인 패키지 안의 .js는 javascript/esm 타입으로 판정되고,⁶ CommonJS 구문을 해석하는 파서 훅은 javascript/auto와 javascript/dynamic에만 등록된다.⁷ 그래서 javascript/esm 모듈 안의 require(...)는 의존성으로 인식되지 않고 평범한 함수 호출로 남는다. Node.js에서도 ESM에는 require가 없다. 다만 webpack 빌드에서는 이 호출을 경고 없이 남겨 둔다.

번들러	빌드	산출물
webpack 5.111.1	성공, 에러와 경고 0건	`require()`가 그대로 남음, 실행 시 `ReferenceError`
Next.js 내장 webpack 5.98.0	실패	페이지 데이터를 모으는 단계에서 `Cannot find module './cjs-dep.cjs'`
Turbopack	성공, 경고 없음	`require()`를 번들
Rolldown	성공, 경고 없음	번들, `__toESM(..., 1)`로 Node.js 호환 방식의 default 처리
esbuild	성공, 경고 없음	번들, `__toESM(require_cjs_default(), 1)`

Next.js의 webpack 모드에서 빌드가 실패한 것은 서버 번들에도 require()가 남았고, 빌드 중 페이지 데이터를 모으는 단계(Failed to collect page data for /)에서 그 서버 번들이 실행됐기 때문이다.

Turbopack: 분석 파일에서 빠진 구분이 모듈 호출에 남는다

`modules.data`의 구조

Next.js의 번들 분석기는 next experimental-analyze로 실행하고, --output을 붙이면 결과를 .next/diagnostics/analyze/data/에 파일로 남긴다. 모듈 사이의 의존성은 그중 modules.data에 들어 있다. JSON 헤더의 modules에는 모듈마다 ident와 path가 있고, 간선 목록은 별도의 이진 영역에 저장된다.⁸

간선은 module_dependencies, async_module_dependencies, traced_module_dependencies와 그 역방향인 *_dependents까지 여섯 목록으로 나뉜다. 앞의 입력에서 클라이언트용 entry.js에 연결된 간선을 읽으면 다음과 같다.

module_dependencies        src/entry.js -> src/esm-dep.js
                           src/entry.js -> src/cjs-default.js
                           src/entry.js -> src/side-effect.js
                           src/entry.js -> src/cjs-dep.js
                           src/entry.js -> src/esm-required.js
async_module_dependencies  src/entry.js -> src/lazy-dep.js

동기 의존성 다섯 개가 한 목록에 들어 있다. 각 간선에는 import와 require()를 구분하는 정보도, 소스의 위치나 지정자도 없다. 쓰지 않은 unused-dep.js는 목록에서 아예 빠져 있다. webpack stats에서 orphan으로 볼 수 있었던 import가 여기에는 기록되지 않는다.

내부 그래프에는 구분이 있었다

Turbopack 내부에서는 import와 require()를 서로 다른 참조 타입으로 다룬다. 각 참조의 ChunkingType에는 청크에 포함되는 방식이 정해져 있다. ESM import(EsmAssetReference)와 CommonJS require()(CjsRequireAssetReference)는 모두 Parallel이지만 필드 값이 다르다.⁹

// turbopack-ecmascript/src/references/esm/base.rs
fn chunking_type(&self) -> Option<ChunkingType> {
    self.extras
        .as_deref()
        .and_then(|e| e.chunking_type)
        .map_or_else(
            || {
                Some(ChunkingType::Parallel {
                    inherit_async: true,
                    hoisted: true,
                })
            },
            |c| c.as_chunking_type(true, true),
        )
}

// turbopack-ecmascript/src/references/cjs.rs
fn chunking_type(&self) -> Option<ChunkingType> {
    self.chunking_type_attribute.map_or_else(
        || {
            Some(ChunkingType::Parallel {
                inherit_async: false,
                hoisted: false,
            })
        },
        |c| c.as_chunking_type(false, false),
    )
}

ChunkingType의 주석을 보면 inherit_async는 의존하는 모듈이 비동기일 때 이를 가져오는 모듈도 비동기가 되는지를 나타낸다. 최상위 await를 쓰는 모듈이 이런 경우에 해당한다. 주석에는 "ESM import에서는 그래야 하지만 CommonJS require에서는 아니다"라고 적혀 있다. hoisted는 가져온 모듈을 항상 먼저 실행하는지, 즉 ESM import의 실행 순서를 따르는지를 나타낸다. 같은 파일의 다른 CommonJS 참조(CjsAssetReference, require.resolve()의 CjsRequireResolveAssetReference)도 require()와 같은 값을 쓴다. 따라서 이 값으로는 ESM import와 CommonJS 참조를 구분할 수 있고, CommonJS 참조끼리는 구분할 수 없다.

이 차이는 분석기에서 modules.data를 만들 때 사라진다. analyze_module_graphs는 그래프를 순회하면서 추적(traced) 대상인지를 먼저 확인한다. 추적 대상은 번들에는 넣지 않지만 실행할 때 필요해서 배포 파일 목록에 남기는 파일로, 정적 자산이나 번들 밖 외부 패키지가 여기에 해당한다. 나머지 간선은 chunking_type에 따라 목록에 넣는다.¹⁰

match reference.chunking_type {
    ChunkingType::Async => {
        all_async_edges.insert((parent_node, node));
    }
    _ => {
        all_edges.insert((parent_node, node));
    }
}

Async가 아닌 간선은 Parallel의 두 필드 값에 관계없이 모두 _ 분기에서 처리된다. 저장하는 값도 (부모, 자식) 쌍뿐이어서 inherit_async와 hoisted의 차이는 분석 파일에 남지 않는다.

산출물에는 `e.i`와 `e.r`로 남는다

같은 페이지를 Turbopack으로 빌드한 산출물에서 페이지 모듈은 다음과 같다.

350,e=>{"use strict";var t=e.i(1398),r=e.i(9422);e.i(1323);let{cjsDep:n}=e.r(1934),{esmRequired:o}=e.r(2989);e.s(["default",0,function(){return(0,t.jsx)("p",{children:String(["M_ESM_DEP",(0,r.default)(),n(),o(),globalThis.M_SIDE_EFFECT,()=>e.A(3105).then(e=>e.lazyDep())].slice(0,5))})}],350)}

e는 모듈 함수가 받는 __turbopack_context__다. 2번 줄의 default import는 e.i(9422), 3번 줄의 부수 효과 import는 e.i(1323), 5번과 6번 줄의 require()는 e.r(1934)와 e.r(2989)가 됐다. 1번 줄의 esm-dep.js는 scope hoisting(여러 ESM 모듈을 한 모듈 함수로 합치는 최적화)으로 페이지 모듈에 합쳐져 문자열만 남았고, 동적 import는 e.A(3105)다. 3105번은 청크를 내려받은 뒤 실제 모듈을 불러오는 로더 모듈이다.

3105,e=>{e.v(t=>Promise.all(["static/chunks/0214m9_id9iur.js"].map(t=>e.l(t))).then(()=>t(9131)))}

어떤 호출을 쓸지는 모듈을 가져오는 구문에 따라 달라진다. CommonJS 모듈을 import한 2번 줄은 e.i이고, ESM 모듈을 require()한 6번 줄은 e.r이다. 한 글자짜리 이름은 코드 생성기의 상수에 정의돼 있다.¹¹

pub const TURBOPACK_REQUIRE: &TurbopackRuntimeFunctionShortcut = make_shortcut!("r");
pub const TURBOPACK_ASYNC_LOADER: &TurbopackRuntimeFunctionShortcut = make_shortcut!("A");
pub const TURBOPACK_MODULE_CONTEXT: &TurbopackRuntimeFunctionShortcut = make_shortcut!("f");
pub const TURBOPACK_IMPORT: &TurbopackRuntimeFunctionShortcut = make_shortcut!("i");

두 호출의 역할은 런타임에서 확인할 수 있다. i는 네임스페이스 객체(import * as ns로 받는, 모듈의 export를 모은 객체)를 제공하고, r은 module.exports를 반환한다. CommonJS 모듈을 가져올 때는 같은 모듈을 가리켜도 반환값이 달라질 수 있다.¹²

function esmImport(
  this: TurbopackBaseContext<Module>,
  id: ModuleId
): Exclude<Module['namespaceObject'], undefined> {
  const module = getOrInstantiateModuleFromParent(id, this.m)

  // any ES module has to have `module.namespaceObject` defined.
  if (module.namespaceObject) return module.namespaceObject

  // only ESM can be an async module, so we don't need to worry about exports being a promise here.
  const raw = module.exports
  return (module.namespaceObject = interopEsm(
    raw,
    createNS(raw),
    raw && (raw as any).__esModule
  ))
}
contextPrototype.i = esmImport

// (중략)

function commonJsRequire(
  this: TurbopackBaseContext<Module>,
  id: ModuleId
): Exports {
  return getOrInstantiateModuleFromParent(id, this.m).exports
}
contextPrototype.r = commonJsRequire

i는 네임스페이스 객체가 없으면 interopEsm으로 module.exports를 감싸고, 그 결과를 저장해 다음 호출에 재사용한다. 2번 줄처럼 CommonJS가 함수를 직접 내보낸 경우에는 default를 만들어 주므로 (0,r.default)()로 함수를 부를 수 있다. r은 module.exports를 그대로 돌려준다.

일반적인 동기 ESM에서는 i와 r이 같은 객체를 반환할 수도 있다. esmExport에서 module.namespaceObject = exports로 지정하기 때문이다.¹³ 호환 처리가 필요한 경우에 Turbopack은 i 안에서 처리하고, webpack은 n.n(...) 같은 함수를 호출 밖에 붙인다. 이번 Turbopack 산출물에서는 이 차이 덕분에 i와 r 호출로 간선 종류를 구분할 수 있었다. 다만 다른 모듈에 합쳐진 ESM import는 호출 자체가 사라져 복원 대상에서 빠진다.

블로그 빌드에서 확인한 차이

이 블로그(Next.js 16.3.5, 커밋 f1ff09a9)에서도 next experimental-analyze --output과 next build를 실행해 분석 파일과 산출물을 비교했다. modules.data의 클라이언트 동기 간선은 서로 다른 경로 쌍으로 세면 3,600개였다. 가져오는 파일의 소스를 파싱하고 지정자를 Node.js의 require 해석 규칙으로 풀어 맞춰 보니, 73%(2,639개)는 어느 구문에서 나온 간선인지 판정할 수 있었다. 그중 require()로 확인한 588개는 모두 node_modules 안에 있었고, 주로 next/dist의 CommonJS 산출물에서 나왔다. 판정하지 못한 961개에는 process 폴리필, JSX 변환이 주입한 jsx-runtime, react를 next/dist/compiled/react로 바꾸는 별칭, 블로그 코드의 @/ 경로 별칭처럼 소스와 맞추기 어려운 간선이 섞여 있다. 그래서 전체 require() 간선이 최대 몇 개인지는 알 수 없다.¹⁴

산출물 쪽에서는 소스맵을 뺀 .next/static의 JavaScript 109개를 coldpath의 modules --graph로 분석해 간선 986개를 복원했고, 그중 절반이 넘는 496개가 e.r 호출이었다. scope hoisting으로 ESM 모듈끼리 한 모듈 함수로 합쳐지면 그 사이의 import 간선은 사라지고, 별도 모듈 함수로 남은 CommonJS 모듈을 부르는 e.r은 남는다. 다만 복원하지 못한 id를 가리키는 호출 527개가 빠져 있고 분석 파일과는 세는 대상부터 달라서, 이 비율을 앞의 판정 결과와 견줄 수는 없다.

Vite: 형식 호환 처리가 남기는 단서

`getModuleInfo`는 import와 `require()`를 한 목록에 담는다

Vite 8은 빌드에 Rolldown을 쓴다. 플러그인에서는 Rollup과 같은 API인 this.getModuleInfo(id)로 그래프를 읽을 수 있다. 앞의 입력에서 entry.js의 모듈 정보를 조회하면 다음과 같다.

{
  "importedIds": [
    "src/esm-dep.js",
    "src/cjs-default.js",
    "src/side-effect.js",
    "src/unused-dep.js",
    "\u0000vite/preload-helper.js",
    "src/cjs-dep.js",
    "src/esm-required.js"
  ],
  "dynamicallyImportedIds": [
    "src/lazy-dep.js"
  ],
  "inputFormat": "es"
}

importedIds 7개에는 import 4개, require() 2개, 그리고 Vite가 동적 import를 처리하면서 주입한 \0vite/preload-helper.js가 함께 들어 있다. Rolldown이 이 목록을 채우는 코드를 보면, 의존성 기록의 종류 중 Import, Require, NewUrl(new URL(..., import.meta.url))을 같은 집합에 넣는다.¹⁵

for (record, info) in raw_import_records.iter().zip(&resolved_deps) {
  match record.kind {
    ImportKind::Import | ImportKind::Require | ImportKind::NewUrl => {
      ecma_view.imported_ids.insert(info.id.clone());
    }
    ImportKind::DynamicImport => {
      ecma_view.dynamically_imported_ids.insert(info.id.clone());
    }
    ImportKind::HotAccept => {
      ecma_view.hmr_info.deps.insert(info.id.clone());
    }
    // for a none css module, we should not have `at-import` or `url-import`
    ImportKind::AtImport | ImportKind::UrlImport => unreachable!(),
  }
}

Rolldown 내부에서는 의존성의 종류를 기록하지만, 플러그인에 공개하는 목록에서는 Turbopack처럼 import와 require()를 합친다. 소스의 위치도 기록하지 않는다. 다만 쓰지 않은 unused-dep.js는 Turbopack과 달리 목록에 남아 있다. inputFormat의 es와 cjs는 조회한 모듈 자체의 형식이다. 형식을 판단할 구문이 없는 side-effect.js는 unknown으로 나온다. 이 값으로 해당 모듈을 어떤 구문으로 가져왔는지는 알 수 없다.

coldpath의 Vite 분석에서는 처음에 본 분류 오류가 없었다. Vite와 Rollup용 플러그인은 transform 훅에서 각 모듈의 소스를 미리 파싱한다. 이후 getModuleInfo에서 읽은 간선과 소스 구문을 맞춰 종류와 위치를 붙인다.¹⁶ 0.6.0으로 같은 입력의 그래프를 만들어 보면 cjs-dep.js와 esm-required.js가 각각 5행 18열과 6행 23열의 require로 나온다. entry.js에서 나가는 간선 중 위치가 없는 것은 소스에 없는 preload-helper.js 하나뿐이었다.

산출물의 도우미 함수가 알려 주는 범위

같은 입력의 산출물에서는 동기로 가져오는 ESM 모듈의 선언이 최상위로 올라가고, CommonJS 모듈은 지연 실행 래퍼로 감싸진다. 축소하지 않은 산출물에서 해당 부분을 옮기면 다음과 같다.

//#region work/auto/src/esm-dep.js
function esmDep() {
  return "M_ESM_DEP";
}
//#endregion
//#region work/auto/src/side-effect.js
var import_cjs_default = /* @__PURE__ */ __toESM((/* @__PURE__ */ __commonJSMin(((exports, module) => {
  module.exports = function cjsDefault() {
    return "M_CJS_DEFAULT";
  };
})))());
globalThis.M_SIDE_EFFECT = "M_SIDE_EFFECT";
//#endregion
//#region work/auto/src/cjs-dep.js
var require_cjs_dep = /* @__PURE__ */ __commonJSMin(((exports, module) => {
  module.exports = { cjsDep() {
    return "M_CJS_DEP";
  } };
}));
//#endregion
//#region work/auto/src/esm-required.js
var esm_required_exports = /* @__PURE__ */ __exportAll({ esmRequired: () => esmRequired$1 });
function esmRequired$1() {
  return "M_ESM_REQUIRED";
}
//#endregion
//#region work/auto/src/entry.js
var { cjsDep } = require_cjs_dep();
var { esmRequired } = __toCommonJS(esm_required_exports);

이 예제에서는 도우미 함수에서 원래 구문의 흔적을 찾을 수 있다. CommonJS 모듈을 import한 2번 줄은 __toESM(...)로 감싸 default를 만든다. require()한 5번 줄은 require_cjs_dep()를 그 자리에서 호출한다. ESM 모듈을 require()한 6번 줄에는 네임스페이스를 CommonJS 객체 모양으로 바꾸는 __toCommonJS(...)가 붙는다.

ESM끼리의 import인 1번 줄은 별도 모듈 호출 없이 함수 선언만 최상위로 올라왔다. CommonJS 모듈을 감싼 __commonJSMin은 처음 호출될 때 모듈 본문을 한 번 실행하는 래퍼다.¹⁷

export var __commonJSMin = (cb, mod) => () => (
  mod || (cb((mod = { exports: {} }).exports, mod), cb = null), mod.exports
);

도우미 함수만으로 원래 구문을 알아낼 수 없는 경우도 있다. 다음은 전역 변수에 값을 쓰는 CommonJS 모듈이다.

// dep.cjs
'use strict'
globalThis.CJS_SIDE_EFFECT = Math.random()
module.exports = {value: 1}

이 모듈을 부수 효과 import로 가져오는 입력 A와 require()로 가져오는 입력 B를 비교했다. 두 입력 모두 이어서 globalThis.finished = true를 실행한다.

// 입력 A
import './dep.cjs'
globalThis.finished = true

// 입력 B
require('./dep.cjs')
globalThis.finished = true

Vite 8.3.2(Rolldown 1.2.12)의 프로덕션 빌드에서 두 입력의 축소 산출물은 완전히 같았다.¹⁸ 두 산출물 모두 dep.cjs의 부수 효과와 CommonJS 래퍼 호출을 포함했고, 네임스페이스 변환 함수는 없었다. 이 경우에는 산출물만 보고 원래 구문을 구분할 수 없다.

//#region 주석도 모듈 경계와 정확히 일치하지는 않는다. 앞의 산출물에서는 원본 2번 줄에서 나온 import_cjs_default 선언이 side-effect.js 구간에 들어가 있다. 코드를 축소하면 도우미 이름도 한 글자로 바뀌므로 v=o(...), u(y) 같은 호출 형태를 보고 역할을 추적해야 한다. 모듈별 함수 등록부도 없어서 coldpath의 modules로는 이 산출물의 모듈 경계를 복원하지 못했다.

앞서 일곱 가지 경우를 넣은 entry.js를 esbuild로 빌드해도 비슷한 호환 처리가 남았다. 기본 입력의 결과를 나란히 놓으면 다음과 같다.

줄	경우	Rolldown	esbuild
1	ESM에서 import	최상위로 끌어올림	최상위로 끌어올림
2	CommonJS를 default import	`__toESM(__commonJSMin(...)())`	`__toESM(require_cjs_default())`
3	부수 효과 import	문장을 그대로 인라인	문장을 그대로 인라인
5	CommonJS를 `require()`	`require_cjs_dep()`	`require_cjs_dep()`
6	ESM을 `require()`	`__toCommonJS(esm_required_exports)`	`(init_esm_required(), __toCommonJS(esm_required_exports))`
9	동적 `import()`	`__vitePreload(() => import(...), [])`	`import(...)`

esbuild는 require()로 가져온 ESM 모듈을 __esm 래퍼로 감싸 require() 시점에 초기화한다. 그래프 정보에서도 원래 구문을 구분할 수 있다. metafile의 imports에는 import-statement, require-call, dynamic-import가 구분돼 있고 원래 지정자(original)도 있다. 다만 metafile에 기록하는 값은 path, kind, original과 import 속성뿐이고, 외부 모듈이면 original 대신 external: true가 붙는다. 소스의 위치는 알 수 없다.¹⁹

coldpath에서 고친 것

소스를 읽어 간선의 종류와 위치를 고치기

coldpath 0.6.0의 Turbopack 어댑터(번들러의 그래프 정보를 coldpath 그래프로 바꾸는 코드)는 modules.data의 세 목록을 이렇게 옮겼다.²⁰

for (const [field, kind] of [
  ['module_dependencies', 'static'],
  ['async_module_dependencies', 'dynamic'],
  ['traced_module_dependencies', 'unknown'],
] as const) {

이 코드에서는 동기 간선이 모두 static이 된다. 이후 소스를 파싱해 위치를 붙이는 단계(enrichLocations)에서도 종류가 같은 구문만 연결했다. 그래서 소스에 있는 require()를 찾고도 그 위치를 붙이지 못했다. coldpath는 분석 경로의 모든 간선이 static일 때 "정적 import 체인"을 전제로 제안한다. 처음 본 page-loader -> index.jsx -> heavy-cjs.js 경로에는 두 간선 모두 static으로 기록돼 있었다.

0.6.1에서는 소스에서 확인할 수 있는 동기 간선부터 다시 분류했다. 가져오는 파일을 파싱해 require() 호출의 대상과 그래프의 대상이 같으면 require로 바꾼다. 이 파일에 인식한 require()가 있지만 어느 import나 require()로도 연결 대상을 설명할 수 없으면 unknown으로 두고 경고에 개수를 남긴다. 나머지는 기존의 static을 유지한다. 구현은 분류 수정 58b1a6a와 패키지 지정자 대응 수정 fec91ef에서 볼 수 있다.

패키지 이름은 가져오는 파일을 기준으로 Node.js의 require 해석 규칙에 따라 풀고, 패키지의 exports에 선언된 대상 파일도 후보로 비교한다. 상대 경로는 확장자를 생략한 경우까지 후보를 차례로 대 본다. 번들러의 별칭과 조건부 해석(package.json exports의 import, require, browser 같은 조건에 따라 다른 파일을 고르는 해석)을 모두 재현하지는 않는다. 그래프에 이미 연결된 모듈을 소스의 어느 구문에서 가져왔는지 찾는 데 이 후보들을 쓴다.

앞에서 본 것처럼 산출물의 e.i와 e.r로도 간선 종류를 구분할 수 있다. 그래도 수정에는 소스를 읽는 방법을 썼다. modules.data의 모듈 항목에는 ident와 path만 있어서 e.r(1934) 같은 산출물의 숫자 id와 바로 이어지지 않고, 분석 파일과 산출물은 따로 실행한 결과다. 블로그 빌드에서 본 것처럼 산출물에서 복원할 수 있는 간선은 일부이고, 다른 모듈에 합쳐진 ESM import는 호출 자체가 남지 않는다. 산출물의 호출에는 소스 위치도 없다. 제안에서 해당 코드를 찾아가려면 어차피 소스를 읽어야 했고, 소스를 읽으면 구문의 종류도 함께 알 수 있었다.

수정 전후의 그래프를 비교하면 다음과 같다. 앞에서는 클라이언트 경로 쌍만 셌지만, 여기서는 어댑터가 만든 그래프 전체에서 위치별 간선까지 세었다. 오른쪽 열은 0.8.2로 다시 내보낸 결과이고, 간선 수와 종류, 위치는 0.6.1부터 같았다.

측정	coldpath 0.6.0	0.8.2
재현 페이지 그래프에서 위치가 붙은 간선	284개 중 3	284개 중 245
블로그 그래프 간선 종류	`static` 3,881, `dynamic` 64	`static` 3,052, `require` 678, `unknown` 172, `dynamic` 64
블로그 그래프에서 위치가 붙은 간선	2,083	2,895
블로그 코드에서 나가는 간선	`static` 208, `dynamic` 4	같음
그중 위치가 붙은 간선	212개 중 28	212개 중 51

블로그 그래프의 간선이 3,945개에서 3,966개로 늘어난 이유는 한 파일에서 같은 모듈을 여러 번 가져오면 위치마다 간선을 남기기 때문이다. 서로 다른 모듈 쌍은 수정 전후 모두 3,941개로 같다. unknown 172개에는 require()를 쓰는 파일에 JSX 변환으로 주입된 jsx-runtime처럼 소스에서 찾을 수 없는 간선도 섞여 있다.

읽을 소스가 없거나 인식한 require()가 없는 파일에는 기존의 static 추정이 남아 있다. Next.js가 만든 가상 모듈 [next]/entry/page-loader.ts에서 페이지로 가는 간선이 그런 경우다. 산출물에서는 e.r 호출이지만 여전히 static으로 기록된다. 따라서 남은 static 간선을 모두 소스에서 확인한 정적 import로 볼 수는 없다.

블로그 코드는 위치를 붙이기도 어려웠다. 블로그 코드끼리 잇는 간선 109개 중 위치가 붙은 것은 31개뿐이다. 위치가 없는 78개 중 47개는 @/ 경로 별칭으로, 10개는 @yceffort/shared 하위 경로로 가져온 간선이다. 둘 다 Node.js 규칙으로는 풀리지 않는 지정자다.

간선을 고친 뒤 제안이 바뀐 과정

간선의 종류와 위치를 바로잡았다고 처음의 제안이 바로 나아지지는 않았다. 10월 4일에 수집한 같은 실행 기록을 coldpath 버전마다 다시 분석하면 heavy-cjs.js의 제안은 이렇게 바뀐다. 그래프도 각 버전으로 다시 내보냈다.²¹

coldpath	`index.jsx -> heavy-cjs.js` 간선	`heavy-cjs.js` 제안
0.6.0	`static`, 위치 없음	`split-review`
0.6.1, 0.8.0	`require`, 3행 18열	`inspect-imports`
0.8.1	최상위 `require`, 3행 18열	`split-review`
0.8.2	최상위 `require`, 3행 18열	`defer-review`

0.6.1의 inspect-imports는 경로가 정적 import 체인도 아니고 import()를 지나지도 않을 때 내는 마지막 분기다. 0.6.1은 경로의 간선이 모두 static일 때만 정적 import 체인으로 봤기 때문에, require 간선이 하나라도 끼면 이 분기로 넘어갔다.²² 설명도 "import 그래프와 부수 효과를 살펴본 뒤 지연 로딩 경계를 정하라"는 일반적인 문장이다. 간선 종류는 바로잡았지만 제안은 오히려 근거를 잃은 셈이다.

최상위에서 호출한 require()는 import처럼, 가져오는 모듈이 실행될 때 대상 모듈을 바로 실행한다. 지연 로딩을 검토할 때 정적 import 체인과 다르게 볼 이유가 없다. 그래서 0.8.1(0e83423)부터는 어댑터가 require 간선이 최상위 호출인지를 topLevel로 기록하고, 분석기는 정적 import와 최상위 require()로만 이어진 경로를 동기 체인으로 본다.²³

impl ImportStep {
    /// Static imports and top-level require() calls evaluate the target while the importer evaluates.
    pub fn synchronous(&self) -> bool {
        self.kind == ImportKind::Static
            || (self.kind == ImportKind::Require && self.top_level == Some(true))
    }
}

블로그 그래프의 require 678개 중 661개가 최상위 호출이었다. 나머지 17개 중 8개는 UMD 래퍼 안의 호출이다. 최상위가 아닌 require()나 unknown 간선이 낀 경로에는 동기 체인을 전제로 하는 제안이 붙지 않는다.

0.8.1에서 제안은 다시 split-review가 됐고, 설명의 앞부분도 "A synchronous import chain (static imports or top-level require() calls)"로 바뀌었다. 뒷부분의 "part of it executes initially"는 import 분류와는 별개인 실행 집계 쪽 결함에서 나온 판정이었고, 이 결함은 0.8.2에서 고쳐졌다.²⁴ 0.8.2에서 heavy-cjs.js에는 다음 제안이 붙었다.

{
  "kind": "defer-review",
  "explanation": "A synchronous import chain (static imports or top-level require() calls) reaches this source. Initially only its top-level declarations were evaluated, with no calls, constructions or property writes other than CommonJS exports; its functions execute in this interaction. Review moving the import behind this interaction and rebuild to measure transfer savings."
}

간선 종류만 고친 0.6.1에서는 제안이 일반적인 문장으로 물러났고, 최상위 require()를 동기 간선으로 다루고 실행 집계까지 고친 뒤에야 버튼을 누를 때만 쓰이는 모듈이라는 재현 페이지의 의도에 맞는 제안이 나왔다.

이 제안은 require()를 버튼 클릭 뒤로 옮기는 것을 검토해 보라는 뜻이다. 이번에는 제안이 바뀌는 과정까지 확인했고, 실제로 코드를 옮겼을 때 동작이나 전송량이 어떻게 달라지는지는 측정하지 않았다.

import와 `require()`의 차이가 남는 곳

같은 입력을 빌드해도 원래 구문을 확인할 수 있는 곳은 번들러마다 달랐다. 그래프에 구문 종류가 기록돼 있는지, 산출물에 이를 알아볼 단서가 남는지를 정리하면 다음과 같다.

번들러	그래프 정보	산출물의 단서와 한계
webpack	stats의 reason에 종류와 위치가 있음	모듈 호출 자체는 같아질 수 있고, 일부 호환 처리는 단서가 됨. 모듈 연결로 호출과 경계가 사라지기도 함
Turbopack	`modules.data`는 import와 `require()`를 동기 목록에 합침	남은 `e.i`와 `e.r` 호출은 구분 가능. 합쳐진 ESM import는 별도 호출이 없음
Vite(Rolldown)	`importedIds`는 import와 `require()`를 합침	일부 형식 호환 함수가 단서가 됨. 부수 효과 import와 `require()`가 같은 산출물이 되는 반례가 있음
esbuild	metafile의 `kind`는 구분되지만 위치는 없음	기본 입력의 형식 호환 함수는 단서가 됨. 합쳐진 ESM import는 별도 호출이 없음

산출물에서 import와 require()를 구분하는 데에는 호환 처리가 단서가 됐다. Turbopack은 이를 i 안에서 처리했고, webpack은 모듈을 가져온 뒤 n.n(...) 같은 함수를 붙였다. 다만 Vite에서 부수 효과 import와 require()가 같은 산출물이 된 것처럼, 실행에 필요한 동작이 같으면 원래 구문의 차이는 남지 않을 수 있다.

그래프를 읽을 때도 API가 무엇을 기록하는지 확인해야 했다. webpack stats의 reasons에서는 구문의 종류와 위치, 활성 여부를 알 수 있었지만, Next.js의 modules.data에서는 동기와 비동기, 추적 대상인지만 구분할 수 있었다. Rolldown의 getModuleInfo는 Rollup 플러그인 API를 따라 의존 대상을 importedIds와 dynamicallyImportedIds로 나눈다.²⁵ Rollup은 CommonJS를 플러그인으로 처리하고,²⁶ Rolldown은 직접 처리하는 require()도 importedIds에 넣는다. 같은 목록에 들어 있다는 이유로 소스의 구문까지 같다고 가정하면, coldpath에서 겪은 것과 같은 분류 오류가 생긴다.

coldpath에서는 그래프에 연결된 모듈을 소스의 어느 구문에서 가져오는지 확인해 분류를 고쳤다. 다만 구문의 종류를 바로잡는 것만으로는 제안이 나아지지 않았다. 최상위 require()가 import와 같은 시점에 대상 모듈을 실행한다는 점을 반영하고 실행 집계 쪽 결함까지 고친 뒤에야 heavy-cjs.js에 defer-review가 붙었다. 제안에 필요했던 것은 구문의 이름보다 실행 시점이었고, 구문의 종류와 위치는 그 시점을 알아내는 수단이었다. 이제 제안에서 해당 모듈을 가져오는 3행 18열의 require()까지 찾아갈 수 있다.

이번 문제를 풀 때는 그래프에서 연결된 모듈을 찾고, 산출물에서 실제 호출을 확인하고, 소스에서 구문과 위치를 찾았다. 분리를 검토할 때도 이렇게 찾은 코드를 첫 진입과 상호작용에서 수집한 실행 기록과 함께 봐야 한다. 어떤 모듈이 연결돼 있는지에서 시작해, 어디서 가져오고 언제 실행되는지까지 확인할 수 있어야 분리할 코드를 구체적으로 짚을 수 있다.

HarmonyImportSideEffectDependency.js#L53-L55, CommonJsRequireDependency.js#L102-L104. stats에 옮기는 코드는 DefaultStatsFactoryPlugin.js#L1548의 object.type = dep ? dep.type : null;이다. ↩
RuntimeTemplate.js#L2394 ↩
CommonJsRequireDependency.js#L330-L337, RequireHeaderDependency.js#L106-L107 ↩
RuntimeTemplate.js#L1593-L1597의 deferredCall. supportsArrowFunction()이 참이면 화살표 함수를, 아니면 bind를 쓴다. ↩
webpack v5.109.0의 "Concatenate CommonJS modules with statically analyzable exports", v5.110.0의 "Wrap concatenated modules in lazy __webpack_require__.cw accessors and inline require()". ↩
config/defaults.js#L1275-L1281에서 descriptionData: {type: "module"}인 .js에 esm 규칙을 적용하고, 그 규칙의 타입은 #L1244-L1245의 JAVASCRIPT_MODULE_TYPE_ESM이다. ↩
CommonJsPlugin.js#L260-L265 ↩
crates/next-api/src/analyze.rs#L368-L375. 헤더 구조체는 #L110-L125, 모듈 항목은 #L70-L74에 있다. ↩
references/esm/base.rs#L672-L686, references/cjs.rs#L152-L162. 같은 파일의 CjsAssetReference는 #L85-L90, CjsRequireResolveAssetReference는 #L301-L311에서 같은 값을 쓴다. 필드의 주석은 turbopack-core/src/chunk/mod.rs#L347-L356에 있다. ↩
crates/next-api/src/analyze.rs#L534-L541. 추적 대상을 거르는 조건은 바로 위 #L519-L532에 있다. ↩
turbopack-ecmascript/src/runtime_functions.rs#L69-L72 ↩
runtime-utils.ts#L467-L484, #L509-L515 ↩
runtime-utils.ts#L221-L239의 esmExport. 236행에서 module.namespaceObject = exports로 지정한다. ↩
판정 스크립트는 scripts/blog-edges.mjs에 있다. 한 파일에서 갈라진 부분 모듈끼리 잇는 간선은 세지 않았다. 판정 결과의 내역(import 2,051, require() 588, 판정 못 함 961)과 블로그 코드에서 나가는 간선 193개의 판정 결과는 FINDINGS.md의 7절에 있다. ↩
crates/rolldown/src/module_loader/module_task.rs#L157-L171 ↩
lib/rollup.ts#L30-L38, #L65-L78 ↩
crates/rolldown/src/runtime/runtime-base.js#L31-L33. __toESM은 #L61-L70, __toCommonJS는 #L71-L74에 있다. ↩
2026년 10월 5일에 Node.js 24.20.0, Vite 8.3.2, Rolldown 1.2.12로 추가 실험을 진행했다. 재현 스크립트는 scripts/interop-counterexample.mjs, 입력과 산출물 원문은 results/interop-counterexample.json에 있다. 실험 디렉터리에서 node scripts/interop-counterexample.mjs로 실행한다. ↩
종류 문자열은 internal/ast/ast.go#L43-L64, metafile을 쓰는 코드는 internal/bundler/bundler.go#L2516-L2521에, 외부 모듈을 쓰는 코드는 #L2478-L2482에 있다. ↩
lib/graph.ts#L295-L299. 종류가 같은 구문만 받아들이는 조건은 #L140에 있다. ↩
버전별 그래프와 분석 결과는 results/coldpath-versions에 있고, scripts/coldpath-versions.sh로 다시 만들 수 있다. 실행 기록과 같은 10월 4일 빌드의 .next가 있어야 한다. ↩
src/recommendations.rs#L45-L47에서 모든 간선이 static인 경로만 정적 import 체인으로 보고, #L89-L94의 마지막 분기에서 inspect-imports를 낸다. ↩
src/graph.rs#L38-L45. 이 판정을 쓰는 분기는 src/recommendations.rs#L49-L98에 있다. ↩
첫 진입에서 heavy-cjs.js가 실행한 것은 모듈 함수가 t.exports에 객체를 대입하는 코드뿐이었고, 모듈 함수의 실행 횟수는 1, 안쪽 compute는 0이다. 그런데 청크 0mlnz1g9-icsv.js에서 heavy-cjs.js의 마지막 매핑(1376열 }},)이 다음 매핑인 index.jsx의 1417열 직전까지 이어지고, 그 사이에 첫 진입에서 실행된 index.jsx 모듈 함수의 시작(1384열 e=>{)이 들어 있어서 그 실행이 heavy-cjs.js의 함수 실행으로 집계됐다. 0.8.2는 매핑 범위를 모듈 함수의 경계에서 자르고(9c89cbc), module.exports와 exports.x 대입을 최상위 부수 효과에서 뺀다(34f908b). 확인 과정은 FINDINGS.md의 8-1절에 있다. ↩
src/rollup/types.d.ts#L193-L212(Rollup v4.64.0) ↩
Rollup 문서의 Importing CommonJS: "Rollup can import existing CommonJS modules through a plugin." ↩

번들러는 import를 어떻게 기억하는가

댓글