测试开发工具【免费下载链接】ts-jestA Jest transformer with source map support that lets you use Jest to test projects written in TypeScript.项目地址https://gitcode.com/gh_mirrors/ts/ts-jest点击查看免费下载导读Babel 7 于 2018 年 9 月发布后带来了babel/preset-typescript让 Babel 用户只需在配置中增加一个 preset 就能“试用”TypeScript。然而该 preset 存在六项关键限制——无类型检查、不支持namespace、不支持const enum、不支持声明合并、不支持遗留import/export语法、以及 JSX 模式下不支持尖括号类型断言。本文以 ts-jest 项目官方文档为骨架结合仓库源码与端到端测试逐一剖析这些限制的底层原因并给出“Babel 处理 JS、ts-jest 处理 TS”的混合方案与配置实操帮助你根据项目形态做出正确的编译链路选型。背景Babel 7 与babel/preset-typescript2018 年 9 月Babel 7 正式发布其中包含一个备受关注的 presetbabel/preset-typescript。它的设计初衷非常明确——让已经在使用 Babel 的 JavaScript 项目能够低门槛尝试 TypeScript不需要把构建链整体迁移到tsc只需在 Babel 配置中追加一个 preset 即可让 Babel 理解并剥离 TypeScript 语法。官方发布时同步发布了 TypeScript 与 Babel 7 合作的技术博客对应版本文档 website/versioned_docs/version-29.0/babel7-or-ts.md 与当前文档 website/docs/babel7-or-ts.md 中的说明。但必须清醒地认识到babel/preset-typescript是一个“语法剥离器”syntax stripper它只负责把.ts文件里的类型注解、接口等 TS 特有语法删除输出标准的 JavaScript并不具备 TypeScript 编译器的完整能力。而 ts-jest 作为 Jest 的 TypeScript transformer走的是 TypeScript 编译器路线。以下六项是“TypeScript ts-jest 能做、而 Babel 7 babel/preset-typescript不能做”的核心差异。局限一没有类型检查No type-checking这是选择 TypeScript 而非 Babel 的最大优势big PROTypeScript 开箱即用地提供类型检查能力。在使用 ts-jest 时测试文件会在编译的同时完成类型检查因此能获得更流畅的 TDD 体验——写完代码立即在测试运行中发现类型错误而不是等到 CI 阶段。下面这段代码TypeScript 会直接抛出类型错误而 Babel 会“安静地”通过const str: string 42背后的原因是编译模型的不同Babel 按孤立模块转译isolated modules每个文件被独立处理没有“项目project”的概念文件之间不做类型关联因此类型错误对它而言根本不存在TypeScript 按项目编译文件属于某个项目由tsconfig.json定义在项目作用域内编译与校验跨文件信息类型、声明、引用都会被纳入考量。这一点在 ts-jest 中有直接的体现默认情况下ts-jest 使用 TypeScript 编译器以“项目上下文”运行保留完整的类型检查与全部特性同时它也提供isolatedModules选项默认false开启后每个文件被当作孤立模块单独转译代价是失去类型检查能力和const enum等特性收益是在jest --no-cache场景下测试运行显著加快。详见 isolatedModules 选项文档其中给出的配置示例如下import type { Config } from jest const jestConfig: Config { // [...] transform: { // ^.\\.[tj]sx?$ to process js/ts with ts-jest // ^.\\.m?[tj]sx?$ to process js/ts/mjs/mts with ts-jest ^.\\.tsx?$: [ ts-jest, { isolatedModules: true, }, ], }, } export default jestConfig需要留意性能权衡isolatedModules: false默认的完整类型检查模式相比true有额外开销。官方建议通过缩小tsconfig.json中include的范围来提升性能——include提供的文件越少测试运行收益越大{ // ...other configs include: [my-typings/*, my-global-modules/*] }但该方案也有代价Caveats过度收缩include可能导致 ts-jest 无法识别测试真正需要的自定义类型声明custom typings、全局模块global modules等文件。建议的解法是测试环境实际需要的文件应恰好被include的 glob 模式覆盖从而兼顾性能提升与行为正确性。局限二不支持namespaceTypeScript 的namespace命名空间用于在全局或模块内部组织代码、避免命名冲突是 TypeScript 独有的组织机制。babel/preset-typescript无法处理它namespace app { export const VERSION 1.0.0 export class App { /* ... */ } }原因在于namespace会被 TypeScript 编译为带有运行时语义的 JavaScript生成作用域包装与属性挂载这属于“需要编译器实现代码生成”的语法而不是简单的类型擦除。Babel 的 preset 只做语法剥离无法生成对应的运行时结构因此直接不支持。这也是 TypeScript 官方早已建议在现代代码中优先使用 ES Module 而非namespace的原因之一。局限三不支持const enumconst enum常量枚举是 TypeScript 的性能优化特性枚举成员在编译期被内联替换为字面量不生成运行时对象。例如const enum Directions { Up, Down, Left, Right, }由于内联需要编译器掌握跨文件或至少当前文件内的完整枚举成员信息const enum无法在“孤立模块”的转译模型下工作——这正是 Babel 不支持它的根本原因。在 ts-jest 仓库中这一点有专门的端到端测试佐证目录 e2e/const-enum/ 下同时存在编译器模式jest-compiler-*.config.ts与转译器模式jest-transpiler-*.config.ts配置测试 e2e/const-enum/tests/const-enum.spec.ts 从bar-constant与foo-constant.d.ts声明 .js实现中导入BarConstEnum、FooConstEnum并断言ONE/TWO的内联值——只有完整编译器模式下const enum才能被正确解析与内联。相比之下普通enum走 Babel 是可行的因为普通枚举会保留运行时对象测试见 e2e/enum/tests/enum.spec.ts。局限四不支持声明合并Declaration MergingTypeScript 允许对同名声明进行声明合并典型场景包括同名enum与namespace合并、同名interface多次声明合并、class与namespace合并等。这一机制依赖 TypeScript 的“项目级”符号表来识别并合并同名的多个声明TypeScript 官方手册的 Declaration Merging 章节对此有系统讲解。babel/preset-typescript按孤立文件逐个转译既没有项目级符号表也不会做合并运算因此无法支持声明合并。局限五不支持遗留import/export语法TypeScript 自带的两种遗留模块语法——import require()与export ——是专门用于兼容 CommonJS 时代模块语义的 TypeScript 专属写法import lib require(lib) // ... export myVar这两种语法既不是标准 ES Module也无法被 Babel 的纯语法剥离模型翻译成等价的 CommonJS 导出/导入结构因此babel/preset-typescript直接不支持。如果你的项目或依赖仍在使用这类遗留写法就需要 TypeScript 编译器即 ts-jest 默认路径来处理。局限六JSX 启用时不支持尖括号类型断言类型断言Type Assertion有两种写法其中“尖括号”写法与 JSX 语法存在歧义冲突const val stringinput当项目开启 JSX.tsx文件时string会被解析器优先当作 JSX 元素起始标签从而无法作为类型断言识别。TypeScript 编译器能够根据上下文区分二者在.ts文件中可用尖括号断言在.tsx中则要求使用as语法而 Babel 的 preset 出于语法优先级处理限制在 JSX 开启时无法支持尖括号类型断言。这与 Babel 对 JSX 与 TypeScript 语法同时处理的解析约束直接相关也是官方文档明确列出的差异之一。混合方案js-with-babel preset——JS 走 Babel、TS 走 ts-jest既然二者各有取舍ts-jest 仓库提供了一种“扬长避短”的官方组合方案让 JavaScript 文件继续由babel-jest处理让 TypeScript 文件由ts-jest处理。这就是js-with-babelpreset 的设计初衷其实现位于 src/presets/create-jest-preset.ts 的createJsWithBabelPresetexport function createJsWithBabelPreset(tsJestTransformOptions: JsWithBabelTransformerOptions {}): JsWithBabelPreset { return { transform: { [JS_TRANSFORM_PATTERN]: babel-jest, // ^.\\.jsx?$ [TS_TRANSFORM_PATTERN]: [ts-jest, tsJestTransformOptions], // ^.\\.tsx?$ }, } }从源码可见它同时注入了两条 transform 规则JS_TRANSFORM_PATTERN^.\\.jsx?$交给babel-jestTS_TRANSFORM_PATTERN^.\\.tsx?$交给ts-jest。这些正则模式定义在 src/constants.ts 中TS_JS_TRANSFORM_PATTERN为^.\\.[tj]sx?$可同时处理 JS 与 TS。preset 的入口文件 presets/js-with-babel/jest-preset.js 直接导出该工厂函数的结果与之对照的 presets/js-with-ts/jest-preset.js 则让 JS 与 TS 全部交给 ts-jest 处理。一个可复制的真实用法是 examples/js-with-babel/jest.config.tsimport type { Config } from jest import { createJsWithBabelPreset } from ts-jest export default { displayName: js-with-babel, ...createJsWithBabelPreset({ babelConfig: true, // 继承项目根目录的 babel 配置 }), } satisfies Config注意这里传入的babelConfig: true表示让 ts-jest 读取项目现有的 Babel 配置文件完整取值与行为见 babelConfig 选项文档用于在转译 TS 时同步 Babel 侧的语法转换例如装饰器、JSX 等。JsWithBabelTransformerOptions类型定义于 src/types.ts它剔除了useESM字段表明该 preset 面向 CJS 场景仓库同时提供 ESM 版本createJsWithBabelEsmPreset配置useESM: true。更多 preset 的对比说明可参考 presets 文档。总结与选型建议能力维度TypeScript ts-jestBabel 7 babel/preset-typescript类型检查✅ 编译与运行同步进行❌ 纯语法剥离无类型检查namespace✅ 支持❌ 不支持const enum✅ 支持编译器模式❌ 不支持孤立模块无法内联声明合并✅ 支持❌ 不支持遗留import require/export ✅ 支持❌ 不支持尖括号类型断言JSX 开启时✅ 支持.ts文件❌ 不支持选型建议如果你的项目追求完整的类型安全、需要const enum/namespace/声明合并等 TS 高级特性、或必须兼容遗留模块语法应选择 ts-jest 的完整编译器模式默认配置即可如果你的项目以 JS 为主、只希望“顺带”支持少量 TS 语法且能接受放弃类型检查可采用babel/preset-typescript或 ts-jest 的isolatedModules: true模式换取更快的转译速度当项目同时包含 JS 与 TS 文件时js-with-babelpreset 提供了“JS 归 Babel、TS 归 ts-jest”的折中组合。无论如何理解本文的六项差异能帮助你避免在不知不觉中踩中 Babel 转译 TS 的语法陷阱。赞分享测试开发工具【免费下载链接】ts-jestA Jest transformer with source map support that lets you use Jest to test projects written in TypeScript.项目地址https://gitcode.com/gh_mirrors/ts/ts-jest点击查看免费下载相关推荐ts-jest 与 Babel 7 对比babel/preset-typescript 的六大局限与 TypeScript 项目级编译的优势ts jest 与 Babel 7 对比babel/preset typescript 的六大局限与 TypeScript 项目级编译的优势 本文基于 ts测试开发工具Taro Babel 配置完全指南babel-preset-taro 的选项解析与源码级原理Taro Babel 配置完全指南babel preset taro 的选项解析与源码级原理 本文基于 Taro 仓库中 packages/babel pre前端跨平台小程序移动开发开发工具MAS Windows 激活脚本 3 步教程一个菜单跑通 4 种激活方式MAS Windows 激活脚本 3 步教程一个菜单跑通 4 种激活方式 MAS 激活脚本Microsoft Activation Scripts下文简称操作系统上一篇pylibcudf 正则引擎实战RegexProgram 的创建、标志位与 GPU 加速字符串 API下一篇终极指南如何用wukong-minimap实时地图插件彻底提升黑神话悟空游戏体验创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 
长河君 · 2026/10/7 2:15:23 · 阅读 1.2k ts-jest 与 Babel 7 + @babel/preset-typescript 选型指南：六大特性差异与源码级解析
测试开发工具【免费下载链接】ts-jestA Jest transformer with source map support that lets you use Jest to test projects written in TypeScript.项目地址https://gitcode.com/gh_mirrors/ts/ts-jest点击查看免费下载导读Babel 7 于 2018 年 9 月发布后带来了babel/preset-typescript让 Babel 用户只需在配置中增加一个 preset 就能“试用”TypeScript。然而该 preset 存在六项关键限制——无类型检查、不支持namespace、不支持const enum、不支持声明合并、不支持遗留import/export语法、以及 JSX 模式下不支持尖括号类型断言。本文以 ts-jest 项目官方文档为骨架结合仓库源码与端到端测试逐一剖析这些限制的底层原因并给出“Babel 处理 JS、ts-jest 处理 TS”的混合方案与配置实操帮助你根据项目形态做出正确的编译链路选型。背景Babel 7 与babel/preset-typescript2018 年 9 月Babel 7 正式发布其中包含一个备受关注的 presetbabel/preset-typescript。它的设计初衷非常明确——让已经在使用 Babel 的 JavaScript 项目能够低门槛尝试 TypeScript不需要把构建链整体迁移到tsc只需在 Babel 配置中追加一个 preset 即可让 Babel 理解并剥离 TypeScript 语法。官方发布时同步发布了 TypeScript 与 Babel 7 合作的技术博客对应版本文档 website/versioned_docs/version-29.0/babel7-or-ts.md 与当前文档 website/docs/babel7-or-ts.md 中的说明。但必须清醒地认识到babel/preset-typescript是一个“语法剥离器”syntax stripper它只负责把.ts文件里的类型注解、接口等 TS 特有语法删除输出标准的 JavaScript并不具备 TypeScript 编译器的完整能力。而 ts-jest 作为 Jest 的 TypeScript transformer走的是 TypeScript 编译器路线。以下六项是“TypeScript ts-jest 能做、而 Babel 7 babel/preset-typescript不能做”的核心差异。局限一没有类型检查No type-checking这是选择 TypeScript 而非 Babel 的最大优势big PROTypeScript 开箱即用地提供类型检查能力。在使用 ts-jest 时测试文件会在编译的同时完成类型检查因此能获得更流畅的 TDD 体验——写完代码立即在测试运行中发现类型错误而不是等到 CI 阶段。下面这段代码TypeScript 会直接抛出类型错误而 Babel 会“安静地”通过const str: string 42背后的原因是编译模型的不同Babel 按孤立模块转译isolated modules每个文件被独立处理没有“项目project”的概念文件之间不做类型关联因此类型错误对它而言根本不存在TypeScript 按项目编译文件属于某个项目由tsconfig.json定义在项目作用域内编译与校验跨文件信息类型、声明、引用都会被纳入考量。这一点在 ts-jest 中有直接的体现默认情况下ts-jest 使用 TypeScript 编译器以“项目上下文”运行保留完整的类型检查与全部特性同时它也提供isolatedModules选项默认false开启后每个文件被当作孤立模块单独转译代价是失去类型检查能力和const enum等特性收益是在jest --no-cache场景下测试运行显著加快。详见 isolatedModules 选项文档其中给出的配置示例如下import type { Config } from jest const jestConfig: Config { // [...] transform: { // ^.\\.[tj]sx?$ to process js/ts with ts-jest // ^.\\.m?[tj]sx?$ to process js/ts/mjs/mts with ts-jest ^.\\.tsx?$: [ ts-jest, { isolatedModules: true, }, ], }, } export default jestConfig需要留意性能权衡isolatedModules: false默认的完整类型检查模式相比true有额外开销。官方建议通过缩小tsconfig.json中include的范围来提升性能——include提供的文件越少测试运行收益越大{ // ...other configs include: [my-typings/*, my-global-modules/*] }但该方案也有代价Caveats过度收缩include可能导致 ts-jest 无法识别测试真正需要的自定义类型声明custom typings、全局模块global modules等文件。建议的解法是测试环境实际需要的文件应恰好被include的 glob 模式覆盖从而兼顾性能提升与行为正确性。局限二不支持namespaceTypeScript 的namespace命名空间用于在全局或模块内部组织代码、避免命名冲突是 TypeScript 独有的组织机制。babel/preset-typescript无法处理它namespace app { export const VERSION 1.0.0 export class App { /* ... */ } }原因在于namespace会被 TypeScript 编译为带有运行时语义的 JavaScript生成作用域包装与属性挂载这属于“需要编译器实现代码生成”的语法而不是简单的类型擦除。Babel 的 preset 只做语法剥离无法生成对应的运行时结构因此直接不支持。这也是 TypeScript 官方早已建议在现代代码中优先使用 ES Module 而非namespace的原因之一。局限三不支持const enumconst enum常量枚举是 TypeScript 的性能优化特性枚举成员在编译期被内联替换为字面量不生成运行时对象。例如const enum Directions { Up, Down, Left, Right, }由于内联需要编译器掌握跨文件或至少当前文件内的完整枚举成员信息const enum无法在“孤立模块”的转译模型下工作——这正是 Babel 不支持它的根本原因。在 ts-jest 仓库中这一点有专门的端到端测试佐证目录 e2e/const-enum/ 下同时存在编译器模式jest-compiler-*.config.ts与转译器模式jest-transpiler-*.config.ts配置测试 e2e/const-enum/tests/const-enum.spec.ts 从bar-constant与foo-constant.d.ts声明 .js实现中导入BarConstEnum、FooConstEnum并断言ONE/TWO的内联值——只有完整编译器模式下const enum才能被正确解析与内联。相比之下普通enum走 Babel 是可行的因为普通枚举会保留运行时对象测试见 e2e/enum/tests/enum.spec.ts。局限四不支持声明合并Declaration MergingTypeScript 允许对同名声明进行声明合并典型场景包括同名enum与namespace合并、同名interface多次声明合并、class与namespace合并等。这一机制依赖 TypeScript 的“项目级”符号表来识别并合并同名的多个声明TypeScript 官方手册的 Declaration Merging 章节对此有系统讲解。babel/preset-typescript按孤立文件逐个转译既没有项目级符号表也不会做合并运算因此无法支持声明合并。局限五不支持遗留import/export语法TypeScript 自带的两种遗留模块语法——import require()与export ——是专门用于兼容 CommonJS 时代模块语义的 TypeScript 专属写法import lib require(lib) // ... export myVar这两种语法既不是标准 ES Module也无法被 Babel 的纯语法剥离模型翻译成等价的 CommonJS 导出/导入结构因此babel/preset-typescript直接不支持。如果你的项目或依赖仍在使用这类遗留写法就需要 TypeScript 编译器即 ts-jest 默认路径来处理。局限六JSX 启用时不支持尖括号类型断言类型断言Type Assertion有两种写法其中“尖括号”写法与 JSX 语法存在歧义冲突const val stringinput当项目开启 JSX.tsx文件时string会被解析器优先当作 JSX 元素起始标签从而无法作为类型断言识别。TypeScript 编译器能够根据上下文区分二者在.ts文件中可用尖括号断言在.tsx中则要求使用as语法而 Babel 的 preset 出于语法优先级处理限制在 JSX 开启时无法支持尖括号类型断言。这与 Babel 对 JSX 与 TypeScript 语法同时处理的解析约束直接相关也是官方文档明确列出的差异之一。混合方案js-with-babel preset——JS 走 Babel、TS 走 ts-jest既然二者各有取舍ts-jest 仓库提供了一种“扬长避短”的官方组合方案让 JavaScript 文件继续由babel-jest处理让 TypeScript 文件由ts-jest处理。这就是js-with-babelpreset 的设计初衷其实现位于 src/presets/create-jest-preset.ts 的createJsWithBabelPresetexport function createJsWithBabelPreset(tsJestTransformOptions: JsWithBabelTransformerOptions {}): JsWithBabelPreset { return { transform: { [JS_TRANSFORM_PATTERN]: babel-jest, // ^.\\.jsx?$ [TS_TRANSFORM_PATTERN]: [ts-jest, tsJestTransformOptions], // ^.\\.tsx?$ }, } }从源码可见它同时注入了两条 transform 规则JS_TRANSFORM_PATTERN^.\\.jsx?$交给babel-jestTS_TRANSFORM_PATTERN^.\\.tsx?$交给ts-jest。这些正则模式定义在 src/constants.ts 中TS_JS_TRANSFORM_PATTERN为^.\\.[tj]sx?$可同时处理 JS 与 TS。preset 的入口文件 presets/js-with-babel/jest-preset.js 直接导出该工厂函数的结果与之对照的 presets/js-with-ts/jest-preset.js 则让 JS 与 TS 全部交给 ts-jest 处理。一个可复制的真实用法是 examples/js-with-babel/jest.config.tsimport type { Config } from jest import { createJsWithBabelPreset } from ts-jest export default { displayName: js-with-babel, ...createJsWithBabelPreset({ babelConfig: true, // 继承项目根目录的 babel 配置 }), } satisfies Config注意这里传入的babelConfig: true表示让 ts-jest 读取项目现有的 Babel 配置文件完整取值与行为见 babelConfig 选项文档用于在转译 TS 时同步 Babel 侧的语法转换例如装饰器、JSX 等。JsWithBabelTransformerOptions类型定义于 src/types.ts它剔除了useESM字段表明该 preset 面向 CJS 场景仓库同时提供 ESM 版本createJsWithBabelEsmPreset配置useESM: true。更多 preset 的对比说明可参考 presets 文档。总结与选型建议能力维度TypeScript ts-jestBabel 7 babel/preset-typescript类型检查✅ 编译与运行同步进行❌ 纯语法剥离无类型检查namespace✅ 支持❌ 不支持const enum✅ 支持编译器模式❌ 不支持孤立模块无法内联声明合并✅ 支持❌ 不支持遗留import require/export ✅ 支持❌ 不支持尖括号类型断言JSX 开启时✅ 支持.ts文件❌ 不支持选型建议如果你的项目追求完整的类型安全、需要const enum/namespace/声明合并等 TS 高级特性、或必须兼容遗留模块语法应选择 ts-jest 的完整编译器模式默认配置即可如果你的项目以 JS 为主、只希望“顺带”支持少量 TS 语法且能接受放弃类型检查可采用babel/preset-typescript或 ts-jest 的isolatedModules: true模式换取更快的转译速度当项目同时包含 JS 与 TS 文件时js-with-babelpreset 提供了“JS 归 Babel、TS 归 ts-jest”的折中组合。无论如何理解本文的六项差异能帮助你避免在不知不觉中踩中 Babel 转译 TS 的语法陷阱。赞分享测试开发工具【免费下载链接】ts-jestA Jest transformer with source map support that lets you use Jest to test projects written in TypeScript.项目地址https://gitcode.com/gh_mirrors/ts/ts-jest点击查看免费下载相关推荐ts-jest 与 Babel 7 对比babel/preset-typescript 的六大局限与 TypeScript 项目级编译的优势ts jest 与 Babel 7 对比babel/preset typescript 的六大局限与 TypeScript 项目级编译的优势 本文基于 ts测试开发工具Taro Babel 配置完全指南babel-preset-taro 的选项解析与源码级原理Taro Babel 配置完全指南babel preset taro 的选项解析与源码级原理 本文基于 Taro 仓库中 packages/babel pre前端跨平台小程序移动开发开发工具MAS Windows 激活脚本 3 步教程一个菜单跑通 4 种激活方式MAS Windows 激活脚本 3 步教程一个菜单跑通 4 种激活方式 MAS 激活脚本Microsoft Activation Scripts下文简称操作系统上一篇pylibcudf 正则引擎实战RegexProgram 的创建、标志位与 GPU 加速字符串 API下一篇终极指南如何用wukong-minimap实时地图插件彻底提升黑神话悟空游戏体验创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考