使用import type或启用@typescript-eslint/consistent-type-imports规则有何弊端与风险？

虽然import type能带来编译优化和代码可读性提升，但启用@typescript-eslint/consistent-type-imports规则确实存在一些容易被忽略的风险：

• 兼容性限制

  • TypeScript 3.8才引入import type语法，如果项目需要兼容更低版本的TS，启用规则后会直接导致编译错误。
  • 部分旧版构建工具（如早期Webpack、Rollup）或其插件对import type的处理存在bug，可能导致打包后的代码丢失必要的导入，或者出现语法错误。

• 自动修复的误判风险

  • TypeScript中有些导出同时是类型和值（比如class、enum），ESLint的规则可能无法准确识别，自动将这类导出的import替换为import type。比如：

    // 被错误修复后
    import type { MyClass } from './my-module';
    const instance = new MyClass(); // 运行时抛出ReferenceError：MyClass is not defined
    

    因为import type导入的内容仅存在于编译阶段，运行时会被完全移除，导致值引用失效。

• 第三方库的导出不规范

  • 部分第三方库没有严格区分类型导出和值导出，甚至通过值导出的方式提供类型定义（比如用declare const模拟类型）。自动替换为import type后，可能导致类型检查失败，或者在运行时找不到依赖的值。

• 导入拆分的冗余与团队适配成本

  • 如果规则配置为fixStyle: 'separate-type-imports'，会将同一模块的类型导入和值导入拆分为两个独立的语句，比如：

    // 修复前
    import { MyType, myFunction } from './my-module';
    // 修复后
    import type { MyType } from './my-module';
    import { myFunction } from './my-module';
    

    这会增加代码行数，若团队习惯混合导入，需要额外的适配成本。而如果使用fixStyle: 'inline-type-imports'（即import { type MyType } from '...'），则需要TypeScript 4.5及以上版本支持，同样存在兼容性问题。

内容的提问来源于stack exchange，提问作者Alex von Brandenfels