2016年搭建的React Native老项目接入TS后Jest测试批量失败如何解决

现有配置的核心冲突点 #

所有调整不生效的根源来自配置优先级与链路逻辑的断层，具体包括：

• ts-jest转换规则重复配置：transform块中既展开了tsjPreset.transform，又手动重复声明了^.+\\.(ts|tsx)?$的处理器，会导致Jest加载转换器时出现优先级覆盖冲突，tsx/ts文件实际走的转换链路不是预期的ts-jest流程
• 预设加载优先级冲突：JS对象展开顺序是先放置...tsjPreset，后面又显式声明preset: 'react-native'，根据Jest配置合并规则，后面的显式声明会完全覆盖前面展开的ts-jest preset预设，等于之前加载的ts-jest默认预设配置被全部冲掉，这是所有调整不生效的核心原因
• 转换匹配正则错误：transformIgnorePatterns的正则写法存在路径前缀错误，误写了不存在的texts/目录前缀，导致node_modules下的依赖被全部排除在转换范围外，和RN preset的默认转换要求不匹配

分类型报错的针对性排查路径 #

按照报错出现的频次逐一排查：

• 占比最高的30个同类型高频报错：优先验证转换优先级问题。修正被覆盖的preset顺序后，确认JS文件走babel-jest、TS/TSX文件走ts-jest的链路不被打断，这类报错90%以上是因为TS文件被错误喂给了RN preset自带的metro babel转换器，没经过TS类型剥离步骤，导致模块导出结构异常
• 已在mock配置中完成声明但仍无法识别的模块报错：优先检查moduleNameMapper的配置是否在preset覆盖时丢失。RN preset默认带了一套完整的moduleNameMapper映射规则，原有配置没有把自定义的mock路径和preset的映射规则做合并，反而因为preset优先级覆盖，自定义的mock路径匹配规则根本没被加载。需要单独把mock的模块映射规则显式写在配置里，不要依赖全局mock文件的自动加载
• 仅2个文件中出现的第三类报错：直接检查对应TS文件的导入路径是否和tsconfig里的paths配置匹配。因为ts-jest默认不会自动读取tsconfig里的paths别名规则，需要在Jest配置里同步把paths映射转成Jest的moduleNameMapper规则，不然老JS文件引用新写的TS文件时，别名解析会失败
• 仅1个文件中复现的第四类报错：检查isolatedModules配置带来的类型导入问题。因为渐进式改造场景下，老JS文件没有类型导入语法，新写的TS文件如果用了不带type标记的导入语句，在isolatedModules开启的情况下，ts-jest会把纯类型导入当成运行时代码打进去，直接触发模块导出未定义的错误，这类问题可以临时在ts-jest配置里开启isolatedModules: true（和tsconfig对齐），临时关闭类型检查先跑通测试

适配低侵入改造的修正后配置参考 #

修正后的jest.config.js #

const { defaults: tsjPreset } = require('ts-jest/presets');

module.exports = {
  // 优先加载React Native核心预设，再叠加ts-jest转换能力，避免预设覆盖冲突
  preset: 'react-native',
  // 合并ts-jest默认转换规则，不手动重复声明TS转换处理器
  transform: {
    ...tsjPreset.transform,
    '^.+\\.(js|jsx)$': 'babel-jest',
  },
  // 扩展名优先级前置TS类型，确保Jest优先识别TS文件
  moduleFileExtensions: ['ts', 'tsx', 'js', 'jsx', 'json'],
  // 显式声明ts-jest配置，单独指定测试环境用的tsconfig文件
  globals: {
    'ts-jest': {
      tsconfig: 'tsconfig.jest.json',
      babelConfig: true,
      isolatedModules: true,
      // 渐进式改造阶段临时关闭TS诊断，避免全量类型检查打断测试流程
      diagnostics: false,
    }
  },
  // 修正transformIgnorePatterns正则，确保所有RN相关依赖经过正确转换
  transformIgnorePatterns: [
    'node_modules/(?!(react-native|@debitoor/react-native-sunstone)/)'
  ],
  // 手动映射tsconfig中配置的路径别名，解决别名解析失败问题
  moduleNameMapper: {
    '^common/(.*)$': '<rootDir>/app/common/$1',
  },
  modulePaths: ['<rootDir>', '<rootDir>/app'],
};

修正后的tsconfig.jest.json #

{
  "compilerOptions": {
    "target": "esnext",
    "module": "commonjs",
    "jsx": "react",
    "esModuleInterop": true,
    "allowJs": true,
    "skipLibCheck": true,
    "moduleResolution": "node",
    "baseUrl": "./app",
    "paths": {
      "common": ["./common"]
    }
  }
}

渐进式改造阶段的避坑要点 #

• 初始接入阶段不要开启全量TS诊断，先通过diagnostics: false让ts-jest只做TS语法转译、不做类型检查，等所有老测试用例跑通后，再逐文件开启类型检查，避免一下子出现大量类型报错打断改造流程
• 不要把主项目的tsconfig直接给Jest使用，主tsconfig是为Metro打包配置的，target设为esnext、module设为esnext，和Jest需要的commonjs模块格式不匹配，一定要单独配置测试环境的tsconfig，和打包配置解耦
• 不要依赖默认的preset合并机制，所有自定义的模块映射、mock规则，都要显式写在Jest配置的moduleNameMapper中，老项目的Metro、Jest配置经过多年迭代，默认合并规则大概率和当前版本的preset存在兼容性问题
• 遇到转换类报错，先临时把出问题的TS文件改回js后缀，验证测试是否恢复正常，确认是TS转换链路的问题，不要上来就排查业务代码逻辑

内容的提问来源于stack exchange，提问作者LasagnaAndroid