从ERR_REQUIRE_ESM错误看现代JavaScript模块化ESLint配置中的CommonJS与ES Module混用指南如果你是一位中高级前端开发者最近在配置ESLint时遇到ERR_REQUIRE_ESM错误那么这篇文章正是为你准备的。这个看似简单的错误背后实际上反映了JavaScript模块化发展历程中的重大变革。随着ES ModuleESM逐渐成为主流我们不得不面对CommonJSCJS与ESM混用带来的各种兼容性问题。本文将带你深入理解模块化的工作原理分析错误根源并提供在ESLint配置中处理模块混用的最佳实践方案。1. JavaScript模块化发展简史要理解ERR_REQUIRE_ESM错误的本质我们需要先回顾JavaScript模块化的发展历程。JavaScript最初并没有内置的模块系统这导致了各种社区解决方案的出现。1.1 CommonJS的兴起与Node.jsCommonJS模块系统最初是为服务器端JavaScript设计的后来被Node.js采用并广泛使用。它的特点是使用require()函数同步加载模块使用module.exports或exports导出模块模块加载是运行时行为// CommonJS模块示例 const fs require(fs); module.exports function() { // 模块内容 };1.2 ES Module的标准化ES6ES2015引入了官方的模块系统——ES Module其特点是使用import和export语法静态分析支持tree-shaking异步加载能力严格模式默认启用// ES Module示例 import fs from fs; export default function() { // 模块内容 }1.3 两种模块系统的关键差异特性CommonJSES Module加载方式同步异步解析时机运行时编译时导出类型动态引用静态绑定循环依赖处理支持但不完美设计上支持严格模式默认不启用默认启用顶层this指向模块本身undefined2. ERR_REQUIRE_ESM错误深度解析当你在项目中看到Error [ERR_REQUIRE_ESM]: require() of ES Module这样的错误时这意味着你正尝试用CommonJS的require()函数加载一个ES Module模块。2.1 错误产生的根本原因这个错误的产生源于Node.js对两种模块系统的处理方式模块识别Node.js通过文件扩展名.js, .mjs, .cjs或package.json中的type字段来判断模块类型加载机制CommonJS的require()不能直接加载ES Module因为两者的加载机制和解析方式完全不同2.2 典型错误场景分析在实际开发中以下几种情况容易引发此错误依赖库更新某个依赖库从CommonJS迁移到了ES Module但你的项目仍在使用require()配置文件格式像ESLint、Babel等工具的配置文件使用了错误的模块格式混合开发环境项目中同时存在CommonJS和ES Module文件且相互引用2.3 错误堆栈解读以原始文章中的错误为例Error [ERR_REQUIRE_ESM]: require() of ES Module C:\Users\USER\Desktop\tindin\node_modules\node-fetch\src\index.js from C:\Users\USER\Desktop\tindin\src\api\services\unsplash.ts not supported.这段错误信息告诉我们问题发生在unsplash.ts文件中它尝试用require()加载node-fetch模块但node-fetch已经是一个ES Module3. ESLint配置中的模块混用问题ESLint作为前端工程化的重要工具其配置文件的模块格式选择尤为关键。下面我们重点探讨ESLint环境下的解决方案。3.1 ESLint配置文件的模块格式ESLint支持多种配置文件格式.eslintrc.js- 通常使用CommonJS.eslintrc.cjs- 明确使用CommonJS.eslintrc.mjs- 明确使用ES Module.eslintrc.json- JSON格式无模块系统问题3.2 常见问题解决方案方案一更改文件扩展名如原始文章中提到的解决方案将配置文件改为.cjs扩展名# 将 commitlint.config.js # 改为 commitlint.config.cjs这种方法明确告诉Node.js这是一个CommonJS模块避免与项目中的ES Module配置冲突。方案二调整package.json配置在项目的package.json中明确指定模块类型{ type: commonjs, scripts: { // ... } }或者为特定文件指定类型{ type: module, scripts: { // ... }, eslintConfig: { // ESLint配置 } }方案三使用动态导入对于必须使用require()加载ES Module的情况可以使用动态import()// 替换 const fetch require(node-fetch); // 使用 const fetch await import(node-fetch).then(m m.default);注意动态import()返回的是一个Promise需要在async函数中使用。3.3 ESLint配置最佳实践基于不同项目类型推荐以下配置方式纯CommonJS项目使用.eslintrc.js或.eslintrc.cjspackage.json中不设置或设置type: commonjs纯ES Module项目使用.eslintrc.mjspackage.json中设置type: module混合模块项目为配置文件使用明确的扩展名.cjs或.mjs使用overrides配置不同模块类型的规则// .eslintrc.cjs示例 module.exports { env: { node: true, es2021: true }, extends: eslint:recommended, parserOptions: { ecmaVersion: latest, sourceType: module // 即使使用CommonJS配置文件也可以检查ES Module代码 }, rules: { // 规则配置 } };4. 现代JavaScript项目模块化实践随着ES Module成为JavaScript标准我们需要逐步将项目迁移到ES Module体系。以下是迁移过程中的关键考虑因素。4.1 渐进式迁移策略评估依赖关系使用npm ls检查项目依赖树识别关键依赖的模块类型配置文件先行先将构建工具(ESLint、Babel等)配置文件迁移使用明确的文件扩展名(.cjs/.mjs)代码分步迁移从项目边缘模块开始逐步向核心代码推进测试保障每次迁移后运行完整测试特别注意模块边界处的测试4.2 工具链配置建议现代前端工具链对ES Module的支持情况工具ESM支持情况备注Node.js≥12.0.0 (实验性)≥14.13.0 (稳定)需要package.json中type:moduleESLint支持配置文件需使用.mjs扩展名Babel完全支持可以转换ESM到CJSWebpack支持需要适当配置TypeScript支持需设置module: ESNext4.3 常见兼容性处理技巧__dirname替代方案// CommonJS中的__dirname在ESM中需要这样实现 import { fileURLToPath } from url; import { dirname } from path; const __filename fileURLToPath(import.meta.url); const __dirname dirname(__filename);JSON文件导入// CommonJS const pkg require(./package.json); // ESM import { createRequire } from module; const require createRequire(import.meta.url); const pkg require(./package.json);条件加载模块async function loadModule() { let myModule; try { // 尝试ESM方式加载 myModule await import(some-module); } catch (e) { // 回退到CommonJS myModule require(some-module); } return myModule; }5. 未来展望与升级建议JavaScript生态系统正在全面转向ES Module作为开发者我们需要拥抱ES Module新项目优先使用ES Module了解互操作掌握两种模块系统互操作的技巧关注工具更新保持工具链的最新版本以获得最佳支持逐步迁移对现有项目制定合理的迁移计划在实际项目中处理ERR_REQUIRE_ESM错误时最关键的是理解错误的根源——模块系统的不匹配。通过明确配置文件格式、合理使用文件扩展名、必要时使用动态导入可以有效地解决这类问题。