深入解析 Oxc transform 的 CommonJS 输出行为为何它保留 ESM 而不做 ESM→CJS 转换【免费下载链接】tsx⚡️ TypeScript Execute | The easiest way to run TypeScript in Node.js项目地址: https://gitcode.com/gh_mirrors/ts/tsx导读本文聚焦 tsx 项目研究笔记中 Oxc transform 的 CommonJS 输出专题核心回答一个问题Oxc 的 NAPI transform 在什么条件下会产生 CommonJS 输出结论是Oxc 的 NAPI transform 没有暴露输出模块格式选项内部模块选项恒为Preserve因此它只保留 ESM 语法sourceType: commonjs只改变解析规则并不会把 ESM 降级为 CJS。读完本文你将理解 Oxc transform 与 esbuild 在 CJS 输出上的能力边界、TypeScript module pass 实际降级的语法子集仅import require()与export 以及这一差异如何决定了 tsx 当前仍以 esbuild 作为通用转换后端、而将 Oxc 标记为模块输出被阻塞的候选后端。Oxc NAPI transform 的模块输出没有 output-module 选项要理解 CommonJS 输出行为首先看 Oxc NAPI transform 暴露了什么。从 notes/oxc-transform/README.md 可知Oxc 的 NAPI transform 是 tsx 研究中的候选后端之一其转换能力覆盖 TypeScript 转换、语义引用分析和生成 helper 行为。关键事实来自关联文档的第一句话NAPI transform 暴露了源语言/模块分类能力但没有暴露输出模块output-module选项。也就是说你可以在调用时告诉 Oxc 输入按什么语言/模块类型解析却无法告诉它 请把结果输出为 CommonJS 或 AMD 格式。这与 esbuild 的format: cjs/format: esm形成了鲜明对比——esbuild 的转换 API 直接支持指定输出格式tsx 正是在transformSync()中设置format: cjs在transform()中设置format: esm见 src/utils/transform/index.ts 与 src/utils/transform/index.ts。既然没有公开的 output-module 选项NAPI 转换内部会怎么做文档指出NAPI 转换层把内部模块选项留在其默认值Preserve上。Preserve意味着转换器不会主动把模块语法改写为其他模块系统——输入的模块形态被原样保留。因此即便你把sourceType指定为commonjs也不会得到 ESM→CJS 的输出转换原因见下一节。sourceType: commonjs的真实作用只改解析规则不产生 CJS 输出sourceType是 Oxc 解析器层面的选项。文档明确指出sourceType: commonjs改变的是解析器规则parser rules而不是 ESM 到 CJS 的输出转换。这句话需要展开理解。在 notes/oxc-transform/configuration.md 中可以看到 Oxc 的模块分类机制文件名后缀如.ts、.tsx、.mts、.cts决定默认语言分类而lang选项可以单独恢复 TS/TSX 语言分类sourceType则单独覆盖解析器的模块类型。换言之Oxc 把语言分类TypeScript / JavaScript与模块分类ESM / CommonJS / script解耦为两个维度lang决定是否按 TypeScript/TSX 语法解析类型注解、import 等sourceType决定解析器允许哪些顶层语法——commonjs意味着按 CommonJS/script 规则解析例如会拒绝某些仅 ESM 合法的语法。因此sourceType: commonjs是一个输入侧的约束它让解析器以 CommonJS 的规则去理解源码但输出侧仍然由内部默认的Preserve模块选项决定即保留源码原有的模块语法。两者一组合结论就很清晰用sourceType: commonjs解析一份含 ESM import/export 的代码Oxc 不会把它降级成require()/module.exports而是要么报解析诊断如import.meta在 script/CommonJS 解析下的报错要么原样保留 ESM 语法输出。TypeScript module pass仅降级import require()与export 既然 NAPI 不做完整 ESM→CJS 输出那么 Oxc 的 TypeScript 转换管线里到底有没有处理模块语法的地方文档给出的答案是TypeScript module pass 只降低import require()和export 这两种 TypeScript 专属的导入导出形式。这是非常重要的边界。import x require(pkg)和export x是 TypeScript 语法中显式表达 CommonJS 语义的形式把它们降级为require()调用 /module.exports赋值是 TypeScript 编译的基础职责。Oxc 的crates/oxc_transformer/src/typescript/module.rs实现了这一小段降级逻辑并且文档特别注明通用 CommonJS 插入general CommonJS insertion属于未来插件的工作范畴当前版本并不包含。由此可以归纳出 Oxc transform 对各类模块语法的处理矩阵语法形式Oxc NAPI transform 的处理import require()降级为 CommonJSTypeScript module passexport 降级为 CommonJSTypeScript module pass普通 ESMimport/export保留 ESM 语法不降级重导出re-export保留 ESM 语法不降级实时绑定live bindings保留 ESM 语义不降级顶层 awaittop-level awaitCommonJS 源分类可诊断但不降级其中最后一行值得单独说明在 CommonJS/script 解析规则下顶层await属于非法语法Oxc 解析器能够报告这一诊断这就是CommonJS source classification can diagnose top-level await的含义但诊断归诊断转换器并不会因此把代码改写成 Promise 链或回调形式——降级能力根本不存在。也就是说Oxc 能告诉你这段代码在 CJS 下不合法却无法帮你把它变成合法的 CJS。一个值得警惕的组合CJS 解析下的import.meta与残留诊断保留 ESM 语法 按 CommonJS 规则解析这两件事叠加会引出一个实际工程陷阱相关的细节记录在 notes/oxc-transform/diagnostics.md 中Oxc 的transformSync()/transform()不会因转换失败直接抛异常而是返回结构化诊断structured diagnostics与代码并存解析器在 script/CommonJS 解析下遇到import.meta会报告一个解析错误severity 为Error但如果后续某个转换步骤例如 define 替换把import.meta替换掉了最终输出的代码里就可能同时存在已被替换的产物与一条过期的 severityError 解析诊断。这意味着在 tsx 这类运行时代码转换场景中不能简单地把存在 Error 级别诊断等同于输出不可用而必须先厘清 source-type/预解析行为再决定如何把剩余的 Error 诊断转换为致命失败。这也是 notes/tsx/transform-backend.md 中Diagnostics这条 gate 被标记为Blocked before adapter的原因之一。与 esbuild 的对比为什么 tsx 的 CJS 输出依赖 esbuild将 Oxc 与 esbuild 并排看能力差异立刻显现。tsx 当前的通用转换后端是 esbuild其 CommonJS 输出路径有两点 Oxc 目前不具备的能力完整的 ESM→CJS 降级在 src/utils/transform/index.ts 的同步转换路径中tsx 向esbuildTransformSync()传入format: cjsesbuild 会把 ESM 语法完整改写为require()/module.exports形式并用 banner/footer 包裹以注入__filename/__dirname语义banner中写入__filename${JSON.stringify(filePath)}并以 IIFE 形式包裹代码。可被静态词法分析器识别的 CJS 导出注解根据 notes/esbuild/commonjs-output.md当 esbuild 面向 Node 生成已知导出的 CommonJS 输出时会附带一段死代码module.exports注解供 Node 的静态 CommonJS 导出词法分析器识别导出形状——这正是 tsx 的 ESM loader 实现 CJS 互操作CJS interop时依赖的机制。而 Oxc 侧正如前文所述普通 ESM 语法会被原样保留连import.meta在 CJS 解析下的残留诊断问题都尚未收敛更谈不上产出带导出注解的 CJS 代码。两者的差距是结构性的而非参数调优可以弥合。tsx 视角CommonJS 输出能力缺失如何阻塞 Oxc 成为通用后端tsx 的研究文档 notes/tsx/transform-backend.md 明确把 Oxc transform 列为被阻塞的通用后端候选Blocked general-backend candidate其中Module output 正是阻塞 gate 之一Module output | Blocked | Public NAPI preserves ordinary ESM and exposes no complete ESM-to-CJS output公共 NAPI 保留普通 ESM 且不暴露完整的 ESM→CJS 输出。这背后是 tsx 的硬性运行时契约tsx 需要同时支持 CommonJS 与 ESM 两条执行路径CJS loader 与 ESM loader对每个文件要么产出可运行的 CJS、要么产出可运行的 ESM。而 Oxc 无法为普通 ESM 文件产出 CJS就无法满足 CJS 路径的转换需求。tsx 的Re-verification matrix中对应地列出了 Module output 契约需要覆盖Async ESM、sync ESM、sync CJS、import.meta、动态 import五类形态的测试且任何后端替换都必须重新验证——这正是因为模块输出行为是整个运行时正确性的基石。从更宏观的视角看tsx 对后端的约束见 notes/tsx/transform-backend.md 的 Invariants还包括必须按 per-file 外部模块模式求值bundle-only 输出不能证明 loader 兼容性、目标为运行中的 Node 版本、不得为自包含函数添加游离的 helper 依赖等。Oxc 在模块输出这一项上的缺口使得它在其他维度如 import elision 的级联类型擦除、结构化诊断即使表现更好也无法整体替换 esbuild。实操验证如何在本地观察 Oxc 与 esbuild 的输出差异仓库本身不包含可直接运行的 Oxc 二进制但你可以通过两份研究笔记与 tsx 源码交叉验证上述结论观察 tsx 的 esbuild CJS 输出阅读 src/utils/transform/index.ts注意transformSync()中format: cjs、platform: node与 banner/footer 的组合理解 tsx 的 CJS 转换契约对应的 ESM 路径见同文件 src/utils/transform/index.ts。观察 esbuild 的导出注解行为对照 notes/esbuild/commonjs-output.md 中关于死代码module.exports注解的说明再用任意含 ESM 导出的小文件执行npx esbuild input.ts --formatcjs即可在输出尾部看到用于导出识别的注解代码。对照 Oxc 的能力边界依次阅读 notes/oxc-transform/README.md文档索引、notes/oxc-transform/configuration.mdlang/sourceType 解耦与默认值、notes/oxc-transform/diagnostics.md结构化诊断与残留 Error 问题最后回到 notes/tsx/transform-backend.mdOxc 候选 gates 表即可把模块输出被阻塞这一结论与每个底层机制一一对上。结论Oxc transform 的 CommonJS 输出行为可以用三句话概括NAPI 无 output-module 选项内部模块选项恒为默认值Preserve公共 API 只暴露源语言/模块分类不暴露输出格式控制sourceType: commonjs是解析器规则而非输出开关它只约束输入侧语法合法性如拒绝 ESM-only 语法、诊断顶层 await 与import.meta不会把 ESM 改写为 CJSTypeScript module pass 只降级import require()与export 普通 ESM 的 import/export、重导出、实时绑定与顶层 await 全部保留 ESM 形态通用 CommonJS 插入留待未来插件。正是这一能力边界决定了 tsx 当前继续以 esbuild具备format: cjs完整降级与可识别的导出注解作为通用转换后端而将 Oxc 视为模块输出 gate 阻塞的候选后端。理解这一差异有助于在评估任何TypeScript 转译器/剥离器作为运行时后端时第一优先检查其 ESM→CJS 输出能力是否真实存在——而非被sourceType: commonjs之类的解析选项名称所误导。【免费下载链接】tsx⚡️ TypeScript Execute | The easiest way to run TypeScript in Node.js项目地址: https://gitcode.com/gh_mirrors/ts/tsx创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
深入解析 Oxc transform 的 CommonJS 输出行为为何它保留 ESM 而不做 ESM→CJS 转换【免费下载链接】tsx⚡️ TypeScript Execute | The easiest way to run TypeScript in Node.js项目地址: https://gitcode.com/gh_mirrors/ts/tsx导读本文聚焦 tsx 项目研究笔记中 Oxc transform 的 CommonJS 输出专题核心回答一个问题Oxc 的 NAPI transform 在什么条件下会产生 CommonJS 输出结论是Oxc 的 NAPI transform 没有暴露输出模块格式选项内部模块选项恒为Preserve因此它只保留 ESM 语法sourceType: commonjs只改变解析规则并不会把 ESM 降级为 CJS。读完本文你将理解 Oxc transform 与 esbuild 在 CJS 输出上的能力边界、TypeScript module pass 实际降级的语法子集仅import require()与export 以及这一差异如何决定了 tsx 当前仍以 esbuild 作为通用转换后端、而将 Oxc 标记为模块输出被阻塞的候选后端。Oxc NAPI transform 的模块输出没有 output-module 选项要理解 CommonJS 输出行为首先看 Oxc NAPI transform 暴露了什么。从 notes/oxc-transform/README.md 可知Oxc 的 NAPI transform 是 tsx 研究中的候选后端之一其转换能力覆盖 TypeScript 转换、语义引用分析和生成 helper 行为。关键事实来自关联文档的第一句话NAPI transform 暴露了源语言/模块分类能力但没有暴露输出模块output-module选项。也就是说你可以在调用时告诉 Oxc 输入按什么语言/模块类型解析却无法告诉它 请把结果输出为 CommonJS 或 AMD 格式。这与 esbuild 的format: cjs/format: esm形成了鲜明对比——esbuild 的转换 API 直接支持指定输出格式tsx 正是在transformSync()中设置format: cjs在transform()中设置format: esm见 src/utils/transform/index.ts 与 src/utils/transform/index.ts。既然没有公开的 output-module 选项NAPI 转换内部会怎么做文档指出NAPI 转换层把内部模块选项留在其默认值Preserve上。Preserve意味着转换器不会主动把模块语法改写为其他模块系统——输入的模块形态被原样保留。因此即便你把sourceType指定为commonjs也不会得到 ESM→CJS 的输出转换原因见下一节。sourceType: commonjs的真实作用只改解析规则不产生 CJS 输出sourceType是 Oxc 解析器层面的选项。文档明确指出sourceType: commonjs改变的是解析器规则parser rules而不是 ESM 到 CJS 的输出转换。这句话需要展开理解。在 notes/oxc-transform/configuration.md 中可以看到 Oxc 的模块分类机制文件名后缀如.ts、.tsx、.mts、.cts决定默认语言分类而lang选项可以单独恢复 TS/TSX 语言分类sourceType则单独覆盖解析器的模块类型。换言之Oxc 把语言分类TypeScript / JavaScript与模块分类ESM / CommonJS / script解耦为两个维度lang决定是否按 TypeScript/TSX 语法解析类型注解、import 等sourceType决定解析器允许哪些顶层语法——commonjs意味着按 CommonJS/script 规则解析例如会拒绝某些仅 ESM 合法的语法。因此sourceType: commonjs是一个输入侧的约束它让解析器以 CommonJS 的规则去理解源码但输出侧仍然由内部默认的Preserve模块选项决定即保留源码原有的模块语法。两者一组合结论就很清晰用sourceType: commonjs解析一份含 ESM import/export 的代码Oxc 不会把它降级成require()/module.exports而是要么报解析诊断如import.meta在 script/CommonJS 解析下的报错要么原样保留 ESM 语法输出。TypeScript module pass仅降级import require()与export 既然 NAPI 不做完整 ESM→CJS 输出那么 Oxc 的 TypeScript 转换管线里到底有没有处理模块语法的地方文档给出的答案是TypeScript module pass 只降低import require()和export 这两种 TypeScript 专属的导入导出形式。这是非常重要的边界。import x require(pkg)和export x是 TypeScript 语法中显式表达 CommonJS 语义的形式把它们降级为require()调用 /module.exports赋值是 TypeScript 编译的基础职责。Oxc 的crates/oxc_transformer/src/typescript/module.rs实现了这一小段降级逻辑并且文档特别注明通用 CommonJS 插入general CommonJS insertion属于未来插件的工作范畴当前版本并不包含。由此可以归纳出 Oxc transform 对各类模块语法的处理矩阵语法形式Oxc NAPI transform 的处理import require()降级为 CommonJSTypeScript module passexport 降级为 CommonJSTypeScript module pass普通 ESMimport/export保留 ESM 语法不降级重导出re-export保留 ESM 语法不降级实时绑定live bindings保留 ESM 语义不降级顶层 awaittop-level awaitCommonJS 源分类可诊断但不降级其中最后一行值得单独说明在 CommonJS/script 解析规则下顶层await属于非法语法Oxc 解析器能够报告这一诊断这就是CommonJS source classification can diagnose top-level await的含义但诊断归诊断转换器并不会因此把代码改写成 Promise 链或回调形式——降级能力根本不存在。也就是说Oxc 能告诉你这段代码在 CJS 下不合法却无法帮你把它变成合法的 CJS。一个值得警惕的组合CJS 解析下的import.meta与残留诊断保留 ESM 语法 按 CommonJS 规则解析这两件事叠加会引出一个实际工程陷阱相关的细节记录在 notes/oxc-transform/diagnostics.md 中Oxc 的transformSync()/transform()不会因转换失败直接抛异常而是返回结构化诊断structured diagnostics与代码并存解析器在 script/CommonJS 解析下遇到import.meta会报告一个解析错误severity 为Error但如果后续某个转换步骤例如 define 替换把import.meta替换掉了最终输出的代码里就可能同时存在已被替换的产物与一条过期的 severityError 解析诊断。这意味着在 tsx 这类运行时代码转换场景中不能简单地把存在 Error 级别诊断等同于输出不可用而必须先厘清 source-type/预解析行为再决定如何把剩余的 Error 诊断转换为致命失败。这也是 notes/tsx/transform-backend.md 中Diagnostics这条 gate 被标记为Blocked before adapter的原因之一。与 esbuild 的对比为什么 tsx 的 CJS 输出依赖 esbuild将 Oxc 与 esbuild 并排看能力差异立刻显现。tsx 当前的通用转换后端是 esbuild其 CommonJS 输出路径有两点 Oxc 目前不具备的能力完整的 ESM→CJS 降级在 src/utils/transform/index.ts 的同步转换路径中tsx 向esbuildTransformSync()传入format: cjsesbuild 会把 ESM 语法完整改写为require()/module.exports形式并用 banner/footer 包裹以注入__filename/__dirname语义banner中写入__filename${JSON.stringify(filePath)}并以 IIFE 形式包裹代码。可被静态词法分析器识别的 CJS 导出注解根据 notes/esbuild/commonjs-output.md当 esbuild 面向 Node 生成已知导出的 CommonJS 输出时会附带一段死代码module.exports注解供 Node 的静态 CommonJS 导出词法分析器识别导出形状——这正是 tsx 的 ESM loader 实现 CJS 互操作CJS interop时依赖的机制。而 Oxc 侧正如前文所述普通 ESM 语法会被原样保留连import.meta在 CJS 解析下的残留诊断问题都尚未收敛更谈不上产出带导出注解的 CJS 代码。两者的差距是结构性的而非参数调优可以弥合。tsx 视角CommonJS 输出能力缺失如何阻塞 Oxc 成为通用后端tsx 的研究文档 notes/tsx/transform-backend.md 明确把 Oxc transform 列为被阻塞的通用后端候选Blocked general-backend candidate其中Module output 正是阻塞 gate 之一Module output | Blocked | Public NAPI preserves ordinary ESM and exposes no complete ESM-to-CJS output公共 NAPI 保留普通 ESM 且不暴露完整的 ESM→CJS 输出。这背后是 tsx 的硬性运行时契约tsx 需要同时支持 CommonJS 与 ESM 两条执行路径CJS loader 与 ESM loader对每个文件要么产出可运行的 CJS、要么产出可运行的 ESM。而 Oxc 无法为普通 ESM 文件产出 CJS就无法满足 CJS 路径的转换需求。tsx 的Re-verification matrix中对应地列出了 Module output 契约需要覆盖Async ESM、sync ESM、sync CJS、import.meta、动态 import五类形态的测试且任何后端替换都必须重新验证——这正是因为模块输出行为是整个运行时正确性的基石。从更宏观的视角看tsx 对后端的约束见 notes/tsx/transform-backend.md 的 Invariants还包括必须按 per-file 外部模块模式求值bundle-only 输出不能证明 loader 兼容性、目标为运行中的 Node 版本、不得为自包含函数添加游离的 helper 依赖等。Oxc 在模块输出这一项上的缺口使得它在其他维度如 import elision 的级联类型擦除、结构化诊断即使表现更好也无法整体替换 esbuild。实操验证如何在本地观察 Oxc 与 esbuild 的输出差异仓库本身不包含可直接运行的 Oxc 二进制但你可以通过两份研究笔记与 tsx 源码交叉验证上述结论观察 tsx 的 esbuild CJS 输出阅读 src/utils/transform/index.ts注意transformSync()中format: cjs、platform: node与 banner/footer 的组合理解 tsx 的 CJS 转换契约对应的 ESM 路径见同文件 src/utils/transform/index.ts。观察 esbuild 的导出注解行为对照 notes/esbuild/commonjs-output.md 中关于死代码module.exports注解的说明再用任意含 ESM 导出的小文件执行npx esbuild input.ts --formatcjs即可在输出尾部看到用于导出识别的注解代码。对照 Oxc 的能力边界依次阅读 notes/oxc-transform/README.md文档索引、notes/oxc-transform/configuration.mdlang/sourceType 解耦与默认值、notes/oxc-transform/diagnostics.md结构化诊断与残留 Error 问题最后回到 notes/tsx/transform-backend.mdOxc 候选 gates 表即可把模块输出被阻塞这一结论与每个底层机制一一对上。结论Oxc transform 的 CommonJS 输出行为可以用三句话概括NAPI 无 output-module 选项内部模块选项恒为默认值Preserve公共 API 只暴露源语言/模块分类不暴露输出格式控制sourceType: commonjs是解析器规则而非输出开关它只约束输入侧语法合法性如拒绝 ESM-only 语法、诊断顶层 await 与import.meta不会把 ESM 改写为 CJSTypeScript module pass 只降级import require()与export 普通 ESM 的 import/export、重导出、实时绑定与顶层 await 全部保留 ESM 形态通用 CommonJS 插入留待未来插件。正是这一能力边界决定了 tsx 当前继续以 esbuild具备format: cjs完整降级与可识别的导出注解作为通用转换后端而将 Oxc 视为模块输出 gate 阻塞的候选后端。理解这一差异有助于在评估任何TypeScript 转译器/剥离器作为运行时后端时第一优先检查其 ESM→CJS 输出能力是否真实存在——而非被sourceType: commonjs之类的解析选项名称所误导。【免费下载链接】tsx⚡️ TypeScript Execute | The easiest way to run TypeScript in Node.js项目地址: https://gitcode.com/gh_mirrors/ts/tsx创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
