解决ESM与CommonJS互操作性中的TypeError：理解与实践-js教程-PHP中文网

解决ESM与CommonJS互操作性中的TypeError：理解与实践

心靈之曲

发布： 2025-10-13 14:02:02

原创

1013人浏览过

解决esm与commonjs互操作性中的typeerror：理解与实践

当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("<project_dir>/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。

优点：

百度作家平台

百度小说旗下一站式AI创作与投稿平台。

146

查看详情

简单直接，修改量小。
无需修改依赖包代码，适用于第三方库。

注意事项：

这种方法仅适用于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模块的强大机制，适用于特定且复杂的集成场景。

在项目初期就规划好模块策略，并对所使用的依赖包的模块格式有所了解，可以帮助开发者有效避免这些互操作性问题，确保项目的顺利开发和运行。

以上就是解决ESM与CommonJS互操作性中的TypeError：理解与实践的详细内容，更多请关注php中文网其它相关文章！