tsx导入openapi-request-validator时加载index.js而非index.d.ts的问题

问题场景 #

项目中使用tsx作为TypeScript开发热重载工具，核心配置及问题表现如下：

package.json核心片段 #

{
  "type": "module",
  "scripts": {
    "dev": "npx tsx watch ./index.js"
  },
  "dependencies": {
    "openapi-request-validator": "^12.1.3",
    "tsx": "^4.19.2",
    "typescript": "^5.7.3"
  }
}

tsconfig.json核心片段 #

{
  "compilerOptions": {
    "module": "ES2022",
    "moduleResolution": "node",
    "esModuleInterop": true
  }
}

执行npm run dev时触发错误：TypeError: OpenAPIRequestValidator is not a constructor，但tsc静态检查能正常识别该包的index.d.ts类型文件。

问题原因 #

1. tsx与tsc的本质逻辑差异
   tsc是静态类型校验工具，仅负责解析.d.ts类型文件做语法和类型检查，不处理代码执行；而tsx是代码运行时工具，直接加载包的可执行文件（如index.js），两者的模块解析逻辑完全独立。tsc的类型解析成功，不代表运行时文件的导出符合预期。

2. 模块规范不兼容
   项目通过"type": "module"启用ES模块规范，但openapi-request-validator的可执行文件采用CommonJS规范导出（如module.exports = OpenAPIRequestValidator）。在ES模块中直接导入CommonJS模块时，ES模块会将其导出内容包裹为一个包含default属性的对象，导致你导入的OpenAPIRequestValidator并非构造函数本身，而是一个对象，因此调用new会报错。

3. tsconfig配置仅作用于静态检查
   tsconfig中的esModuleInterop: true是给tsc用的，用于在类型检查时兼容CommonJS模块的导入语法，但这个配置不会影响tsx的运行时行为——tsx不会自动转换CommonJS到ES模块的导出适配。

解决办法 #

• 手动调整导入方式，明确获取CommonJS导出的默认值：

  // 方式一：直接取default导出
  import { default as OpenAPIRequestValidator } from 'openapi-request-validator';
  
  // 方式二：先导入再解构
  import OpenAPIRequestValidator from 'openapi-request-validator';
  const Validator = OpenAPIRequestValidator.default;
  

• 可在tsconfig.json的compilerOptions中添加allowSyntheticDefaultImports: true，配合esModuleInterop优化导入的类型提示，但优先建议手动调整导入以确保运行时稳定。

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