当ESM项目尝试导入CommonJS模块的默认导出类时，常会遇到“TypeError: TestClass is not a constructor”错误。这源于ESM对CJS默认导出的特殊处理，将其包装在.default属性中。本文将深入解析此问题，并提供三种实用的解决方案：通过.default属性访问、统一模块格式，或利用Node.js的createRequire函数，以确保模块间的平稳协作。
在现代JavaScript开发中，ECMAScript模块（ESM）和CommonJS（CJS）是两种主要的模块系统。尽管ESM已成为标准，但许多现有库和项目仍采用CJS格式。当一个配置为ESM的TypeScript或JavaScript项目尝试导入一个CJS模块的默认导出类时，开发者可能会在运行时遇到一个令人困惑的TypeError: TestClass is not a constructor错误。本文将深入探讨这一问题的根源，并提供多种有效的解决方案。
问题剖析：为什么TestClass不是构造函数？
为了更好地理解这个问题，我们首先来看一个典型的项目配置：
主项目 (myproject) 配置:
- package.json 中包含 "type": "module"，表明这是一个ESM项目。
- tsconfig.json 配置了ESM相关的编译选项。
- src/index.ts 尝试通过 import TestClass from "testpackage"; 导入一个默认导出类。
依赖包 (testpackage) 配置:
- package.json 未指定 "type": "module"，或显式配置为CJS。
- tsconfig.json 中 "module": "CommonJS"，表明这是一个CJS模块。
- src/testFile.ts 中 export default class TestClass { ... } 导出一个默认类。
- 编译后的 dist/testFile.js 包含CJS特有的 Object.defineProperty(exports, "__esModule", { value: true }); 和 exports.default = TestClass; 结构。
当ESM项目尝试 import TestClass from "testpackage"; 一个CJS模块时，Node.js和TypeScript的ESM加载器会以一种特殊的方式处理CJS的默认导出。它不会直接将CJS的 module.exports 或 exports.default 视为ESM的默认导出。相反，它会将整个CJS模块的导出对象（即 module.exports）作为一个命名空间对象导入。CJS模块的默认导出（如果存在）会被包装在这个命名空间对象的 .default 属性中。
因此，当你在ESM代码中写 import TestClass from "testpackage"; 时，TestClass 实际上不是你期望的类构造函数，而是一个包含 .default 属性的模块命名空间对象。直接尝试 new TestClass(...) 就会导致 TypeError: TestClass is not a constructor，因为你正在尝试实例化一个普通对象，而不是一个可构造的类。
如果你在tsconfig.json中设置了"moduleResolution": "nodenext"，TypeScript甚至会在编译时就捕获到这个错误：
error TS2351: This expression is not constructable.
Type 'typeof import("/node_modules/testpackage/dist/testFile")' has no construct signatures. 这进一步证实了TypeScript编译器也识别到 TestClass 在这种情况下并非一个构造函数类型。
解决方案一：通过.default属性访问
最直接且无需修改依赖包代码的解决方案是，显式地从导入的模块命名空间对象中访问 .default 属性。
原理： 由于ESM加载器将CJS的默认导出包装在导入对象的 .default 属性中，我们只需导入整个模块，然后从中提取出 .default 属性即可。
示例代码： 假设你的主项目 myproject 的 src/index.ts 如下：
// myproject/src/index.ts
import TestModule from "testpackage"; // 导入整个模块命名空间对象
// 显式地从TestModule中获取默认导出
const TestClass = TestModule.default;
new TestClass({ arg1: "Hello, World!" }); // 现在可以正确实例化通过这种方式，TestClass 变量将正确地指向CJS模块导出的类构造函数，从而避免 TypeError。
优点：
PHP经典实例（第2版）能够为您节省宝贵的Web开发时间。有了这些针对真实问题的解决方案放在手边，大多数编程难题都会迎刃而解。《PHP经典实例(第2版)》将PHP的特性与经典实例丛书的独特形式组合到一起，足以帮您成功地构建跨浏览器的Web应用程序。在这个修订版中，您可以更加方便地找到各种编程问题的解决方案，《PHP经典实例(第2版)》中内容涵盖了：表单处理；Session管理；数据库交互；使用We
- 简单直接，修改量小。
- 无需修改依赖包代码，适用于第三方库。
注意事项：
- 这种方法仅适用于CJS模块的默认导出。如果依赖包使用命名导出（例如 export class MyClass { ... }），则可以直接使用 import { MyClass } from "testpackage";。
解决方案二：统一模块格式
从根本上解决ESM与CJS互操作性问题的最佳实践是统一所有相关代码的模块格式。
方法一：将主项目转换为CJS 如果你的项目主要依赖CJS模块，并且没有强烈的ESM需求，你可以将主项目也配置为CJS。
- 在 myproject/package.json 中移除 "type": "module" 行。
- 或者，在 tsconfig.json 中将 "module" 选项设置为 "CommonJS"。 这样做之后，你的项目将以CJS方式加载模块，从而避免ESM与CJS之间的转换问题。
方法二：将依赖包转换为ESM 如果你有权限修改 testpackage，并且它是一个你维护的内部包，那么将其转换为ESM是更现代化的做法。
- 在 testpackage/package.json 中添加 "type": "module"。
- 在 testpackage/tsconfig.json 中将 "module" 选项设置为 "ESNext" 或其他ESM兼容格式（如 "ES2020"），并确保 outDir 和 declaration 等选项配置正确。
- 确保 testpackage/package.json 中的 exports 字段正确配置，以支持ESM和CJS的条件导出（如果需要同时支持两种格式）。
优点：
- 从根本上解决模块格式不兼容问题，简化项目结构和理解。
- 统一的模块格式有助于未来的维护和生态系统集成。
注意事项：
- 模块格式转换可能涉及较大的代码修改和迁移工作，特别是对于大型项目或需要兼容旧版Node.js环境的场景。
解决方案三：使用Node.js createRequire 函数
Node.js提供了一个 createRequire 函数，允许你在ESM模块中动态地创建一个CJS require 函数，用于加载CJS模块。这提供了一种在ESM环境中按需引入CJS模块的灵活方式。
原理：createRequire 函数接收一个文件路径或URL（通常是 import.meta.url），并返回一个类似于CJS环境中全局 require 函数的实例。你可以使用这个实例来加载任何CJS模块。
示例代码：
// myproject/src/index.ts
import { createRequire } from 'module'; // 从Node.js的'module'模块导入createRequire
// 创建一个CJS require函数，其上下文基于当前ESM文件的URL
const require = createRequire(import.meta.url);
// 使用创建的require函数加载CJS模块
const TestClass = require('testpackage');
new TestClass({ arg1: "Hello, World!" }); // 现在可以正确实例化优点：
- 允许在ESM项目中精确控制CJS模块的加载，而无需全局改变模块格式。
- 适用于需要混合使用ESM和CJS的复杂场景，或当其他解决方案不适用时。
注意事项：
- createRequire 是Node.js特有的API，不适用于浏览器环境。
- 它的使用场景通常是当你需要从ESM代码中加载一个纯CJS模块，并且这个CJS模块的导出方式与ESM的默认导出规则不兼容时。
总结与最佳实践
ESM与CJS模块互操作性是现代JavaScript开发中一个常见的挑战，尤其是在处理默认导出类时。理解ESM加载器如何处理CJS默认导出是解决问题的关键。
- 首选解决方案一： 对于大多数情况，通过 .default 属性访问是最简单直接的修复方法，尤其适用于引入第三方CJS库。
- 长期最佳实践： 如果可能且项目规模允许，统一所有模块的格式（无论是全部迁移到ESM还是保持CJS）是消除互操作性问题的根本途径，有助于简化项目结构和未来的维护。
- 灵活的按需加载： createRequire 提供了一种在ESM项目中按需加载CJS模块的强大机制，适用于特定且复杂的集成场景。
在项目初期就规划好模块策略，并对所使用的依赖包的模块格式有所了解，可以帮助开发者有效避免这些互操作性问题，确保项目的顺利开发和运行。
