在现代JavaScript和TypeScript项目中，模块化是代码组织的核心。随着ECMAScript 2015（ES6）标准的普及，ES模块（ESM）的import/export语法已成为主流，并被TypeScript原生支持。然而，许多开发者在从旧项目迁移或处理某些第三方库时，可能会遇到使用CommonJS模块的require语句，这在严格的TypeScript和ESLint配置下会引发@typescript-eslint/no-var-requires错误。
理解@typescript-eslint/no-var-requires错误
这个错误提示Require statement not part of import statement，意味着ESLint（特别是@typescript-eslint插件）检测到你在TypeScript文件中使用了require()函数来导入模块，而它期望的是ES模块的import语句。此规则旨在强制项目遵循ES模块规范，以获得更好的静态分析、Tree Shaking优化以及统一的模块管理方式。
例如，以下代码在TypeScript项目中会触发此错误：
const Koa = require("koa"); // 触发错误：@typescript-eslint/no-var-requires解决方案一：采用ES模块导入语法（推荐）
最推荐且符合现代TypeScript开发实践的方法是，将所有require语句替换为ES模块的import语法。这种方法不仅解决了错误，还使代码更符合标准，并能更好地利用TypeScript的类型检查和ESLint的代码规范。
将上述require语句改为import，示例如下：
import Koa from 'koa'; // 正确的ES模块导入方式
优点：
- 标准化： 符合ECMAScript模块规范，是未来JavaScript和TypeScript的发展方向。
- 静态分析： 编译器和工具可以更好地进行静态分析，例如检测未使用的导入或循环依赖。
- Tree Shaking： 有助于打包工具（如Webpack、Rollup）进行Tree Shaking，只打包实际使用的代码，从而减小最终文件体积。
- 类型安全： 与TypeScript的类型系统无缝集成，提供更好的类型推断和检查。
注意事项：
- 确保你的tsconfig.json文件中的module选项设置为支持ES模块的格式，例如"esnext"、"commonjs"（虽然commonjs也支持import，但esnext更推荐用于纯ESM项目）或"node16"等。
- 如果导入的是一个没有默认导出的CommonJS模块，你可能需要使用命名空间导入：import * as fs from 'fs'; 或针对特定导出使用命名导入：import { readFileSync } from 'fs';。
解决方案二：禁用ESLint规则
在某些特定场景下，例如处理遗留代码、与某些特定只提供CommonJS接口的库交互，或者在短期内无法进行大规模代码迁移时，你可以选择禁用@typescript-eslint/no-var-requires这条ESLint规则。
要禁用此规则，你需要编辑项目根目录下的.eslintrc.js（或.eslintrc.json）配置文件，在rules部分添加或修改如下配置：
// .eslintrc.js
module.exports = {
// ...其他配置
rules: {
// ...其他规则
"@typescript-eslint/no-var-requires": "off" // 禁用此规则
}
};何时考虑禁用：
- 临时解决方案： 在大型项目迁移到ES模块的过程中，作为临时的妥协方案。
- 特定第三方库： 某些库可能仅提供CommonJS格式，且没有相应的类型定义（@types/包），导致import难以直接使用。
- 构建工具限制： 极少数情况下，构建工具链可能对ES模块支持不完善。
风险与建议：
- 不推荐长期使用： 禁用此规则意味着你放弃了ESLint在此方面的代码规范检查，可能导致项目中出现混合的模块导入风格，降低代码一致性和可维护性。
- 隐藏潜在问题： 禁用规则可能会掩盖本可以通过ES模块解决的兼容性问题。
- 优先重构： 强烈建议将禁用规则作为临时方案，并最终目标是重构代码以完全采用ES模块。
总结与建议
@typescript-eslint/no-var-requires错误是TypeScript项目向现代化ES模块化标准迁移过程中的一个常见提示。解决此问题的最佳实践是拥抱ES模块的import语法。它不仅能消除错误，更能提升代码质量、可维护性和构建效率。
如果遇到必须使用require的情况，应仔细评估其必要性，并考虑是否可以通过其他方式（如查找ES模块兼容版本、创建类型声明文件）来避免禁用ESLint规则。将禁用规则作为最后的手段，并在项目规划中安排时间进行模块化重构，以确保项目的长期健康发展。
