Node.js+TypeScript项目安装jest后tsc报d.ts不是模块错误如何解决

错误完全来自tsconfig.json的错误配置，和jest本身、类型声明文件的内容逻辑无关：
你配置的"paths": {"*": ["./src/types"]}会匹配所有模块导入路径，TS处理任何import语句时，都会优先去./src/types目录下查找对应模块。安装jest时自动携带了@types/babel__core等依赖，这些依赖内部的@babel/*导入被你的paths规则匹配，指向了你本地的src/types/index.d.ts，但该文件没有export语句，不属于模块化类型文件，因此TS抛出「不是一个模块」的报错。

1. 修正tsconfig.json配置
   删除错误的paths配置，新增typeRoots配置指定自定义类型目录即可，既不影响第三方包导入，也能让你自定义的全局类型生效：

{
  "compilerOptions": {
    "target": "ES2020",
    "lib": ["ESNext"],
    "module": "commonjs",
    "allowJs": true,
    "outDir": "./build",
    "esModuleInterop": true,
    // 删除原有的paths配置，新增以下配置
    "typeRoots": ["./node_modules/@types", "./src/types"]
  },
  "include": ["app.ts", "src"],
  "exclude": [
    "**/*.spec.?s",
    "**/*.test.?s"
  ]
}

如果后续需要配置路径别名（比如@/指向src目录），不要用*通配匹配所有路径，指定别名前缀即可，例如：

"paths": {
  "@/*": ["./src/*"]
}

2. 规范全局类型声明文件写法
   为了避免类型作用域冲突，修改src/types/index.d.ts为标准全局类型写法：

declare global {
  type Text = string;
}
// 加空export让TS将该文件识别为模块，避免全局类型污染
export {}

3. 验证修复
   执行以下命令验证修复效果：

rm -rf node_modules package-lock.json
npm install
npx tsc

编译不会再抛出类型错误，业务代码中也能正常使用自定义的Text类型，jest相关功能也可正常使用。

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