首页/开发/代码质量与评审速查/typescript-eslint:类型感知规则
规范与静态检查65 条

typescript-eslint:类型感知规则

TypeScript 的 ESLint 插件体系:部分规则需要类型信息(parserOptions.project),预设如 recommended-type-checked、strict-type-checked,检查能力更强但更慢。

typescript-eslint 是什么

typescript-eslint 是让类型检查器与 ESLint 协作的插件体系:一部分规则只做语法分析,另一部分需要读取类型信息,因此能发现「忘记等待 Promise」「把 any 一路传下去」这类纯语法规则看不到的问题。代价是需要构建类型信息,首次运行与大型仓库的开销明显更高。

基本信息

类型感知规则需要类型信息,检查能力明显强于纯语法规则
预设recommended-type-checked、strict-type-checked 一类按强度分级的预设
成本首次类型构建有开销,仓库越大越明显
配置前提需要正确指向项目的类型配置,否则类型规则会静默失效

规则配置示例

规则配置示例
rules: {
  "@typescript-eslint/no-floating-promises": "error",   // 未处理的 Promise
  "@typescript-eslint/no-misused-promises": "error",    // Promise 用在同步位置
  "@typescript-eslint/no-explicit-any": "warn",         // 显式 any
  "@typescript-eslint/await-thenable": "error"          // 对非 Promise 使用 await
}

落地策略

  • 源码目录开启类型感知规则,生成代码与测试目录使用轻量配置。
  • 从 recommended 起步,再逐类提升到严格预设,避免一次全开。
  • 确认类型配置指向正确:指向不完整时类型规则可能不报错也不生效。
  • 把检查接入 CI,并为大型仓库预留构建时间。
  • 用错误码或规则名做局部豁免,并写明原因。
  • 为类型感知规则单独跑一条流水线:失败时能直接看出是类型问题而不是运行问题。
  • 报错时优先修类型本身:用类型断言绕过检查,等于把问题推迟到运行时。

类型感知的收益

问题纯语法规则类型感知规则
未处理的异步调用看不到可识别并报错
any 扩散只能看显式标注可追踪赋值与传参路径
误用 Promise看不到可识别同步位置使用异步返回值
未使用变量与导入可识别同样可识别,无需类型信息
常见取舍:源码目录开类型感知规则,生成代码与测试目录用轻量配置,兼顾检查能力与执行时间。
类型配置指向不完整时,类型规则可能既不报错也不生效:配置完成后要用一条已知问题验证规则确实在工作。

易错点

  • 类型配置不完整:类型规则静默失效,检查形同摆设。
  • 对所有目录都开严格类型规则:CI 时间明显拉长,团队开始绕开检查。
  • 用大量行内禁用注释:类型信息带来的收益被逐条关掉。
  • 把格式问题交给这类规则处理:格式应交给格式化器,避免工具职责重叠。

数据来源与参考

  • typescript-eslint 官方文档(typescript-eslint.io)
​‌‌​​‌​​​‌‌​‌‌‌‌​‌‌​​​‌‌​‌‌‌​​‌‌​​‌​‌‌‌​​‌‌‌​​​‌​‌‌​‌​​‌​‌‌‌​​​‌​‌‌​‌​​‌​‌‌​​​‌‌​‌‌‌​‌​​​‌‌​‌‌‌‌​​‌​‌‌‌​​‌‌​​​‌‌​‌‌​‌‌‌‌​‌‌​‌‌​‌