TypeScript-ESLint 中 auto-accessor 类型推断的规则缺陷分析

TypeScript 5.7 引入的 auto-accessor 语法为类属性提供了更简洁的访问器定义方式。然而，在 TypeScript-ESLint 项目中，我们发现多个规则对 auto-accessor 的支持存在不足，特别是 no-inferrable-types 规则出现了明显的类型推断缺陷。

问题现象

当开发者使用 auto-accessor 语法定义类属性时，即使显式声明了可推断的类型注解，no-inferrable-types 规则也不会报错。例如：

class Foo {
  props: number = 5; // 正确触发错误
  accessor accessorProps: number = 5; // 未触发错误（错误行为）
}

这种不一致性会导致代码库中出现冗余的类型注解，违背了 TypeScript 类型推断的设计初衷。

技术背景

auto-accessor 是 TypeScript 5.7 引入的新语法糖，它会在编译时自动生成 getter 和 setter。与普通属性不同，auto-accessor 在 AST 中被表示为独立的节点类型，而不是简单的属性修饰符（如 readonly）。

影响范围

经过深入分析，我们发现这个问题不仅限于 no-inferrable-types 规则。至少有六个核心规则对 auto-accessor 的支持不完整：

1. explicit-module-boundary-types - 对 auto-accessor 的返回类型检查缺失
2. prefer-return-this-type - 未正确处理 auto-accessor 的 this 类型推断
3. no-unsafe-assignment - auto-accessor 的类型安全检查不完善
4. explicit-member-accessibility - 访问修饰符检查不完整
5. consistent-generic-constructors - 泛型构造函数推断问题
6. class-methods-use-this - this 使用检查缺失

解决方案建议

要彻底解决这些问题，需要在规则实现中：

1. 为 auto-accessor 添加专门的 AST 节点处理逻辑
2. 确保类型推断系统能正确处理 auto-accessor 的特殊语义
3. 在测试用例中增加 auto-accessor 的各种使用场景

对于开发者而言，在 TypeScript-ESLint 修复这些问题前，建议在使用 auto-accessor 时保持警惕，必要时手动添加类型注解以确保类型安全。

总结

TypeScript 新特性的引入往往会带来工具链的适配挑战。auto-accessor 的类型推断问题提醒我们，在采用新语法时需要同步验证相关工具的支持情况。对于 lint 规则开发者来说，这也强调了全面测试覆盖的重要性，特别是对新语法特性的支持测试。