mcpField
F
fix-ts-errors

fix-ts-errors

github.com/bhagyamudgal开发2110 次安装5 天前更新
代码仓库

关于 fix-ts-errors

fix-ts-errors 是在错误源头修复 TypeScript 类型问题的技能,并反复运行工作区类型检查直至通过。它会追踪类型变更在工作区中的影响,并在报告前审查绕过类型检查的写法。

主要功能

  1. 01运行工作区类型检查
  2. 02从源头修复错误
  3. 03追踪跨包错误影响
  4. 04审查类型检查逃逸写法
  5. 05多轮失败后停止并说明

适用场景

  1. 01修复变更文件中的 TypeScript 错误
  2. 02纠正共享包的类型定义
  3. 03检查类型变更对导入方的影响
  4. 04审查类型断言和错误抑制指令

安装

复制下面的命令,在终端中运行。

$npx skills add https://github.com/bhagyamudgal/skills --skill fix-ts-errors

安装后在 Claude Code 中输入/fix-ts-errors确认已加载。

详细介绍

修复 TypeScript 错误

我会从源头修复类型,并反复运行工作区检查,直到退出码为 0。我不会绕过这些错误。

工作流

步骤 1:确定目标文件
  • 如果用户指定了文件,我就使用这些文件。
  • 如果用户说“已更改的文件”,我会对已暂存和未暂存的 .ts 与 .tsx 文件运行 git diff --name-only HEAD,并对未跟踪文件运行 git ls-files --others --exclude-standard。
  • 如果不明确,我会询问要处理哪些文件。
步骤 2:让检查报错

我会运行工作区类型检查:pnpm type-check 或 turbo type-check;对于纯 TS 项目,则运行 bunx tsc --noEmit。检查输出是循环修复的事实依据。

我只会使用 IDE 诊断、LSP 工具或 mcp__ide__getDiagnostics 来定位检查已报告的错误。IDE 诊断按文件提供,且在工作区包边界之间并不可靠,因此只能缩小范围,不能作为判断依据。

步骤 3:修复错误

对于发现的每个错误,我都会阅读错误位置附近的文件,理解根本原因,然后采用类型安全的正确方式从源头修复。

我会按以下顺序修复。缺少导入时补上导入。类型不匹配时,从源头修正声明。缺少属性时,使其与源类型定义保持一致。遇到 null 或 undefined 时,用类型守卫缩小范围或提前返回。遇到泛型类型问题时,显式指定类型参数。

每个错误都会通过真正的类型解决。我会补上缺失的导入、缩小联合类型、从源头拓宽签名,或使用 z.infer 从 schema 推导类型。只有在注释中说明第三方类型缺陷时,才会保留 as。

步骤 4:重新验证

我会重新运行相同的工作区检查。退出码为 0 才算通过。

文件中的波浪线消失不代表检查通过。类型变更可能影响导入该文件的代码,因此我会沿着影响链追查到工作区边界后再汇报。如果出现新错误,我会返回步骤 3。

步骤 5:检查逃生口

检查通过后,我会 grep 已更改的行,查找以下四种逃生口:as 断言(不包括 as const)、@ts-ignore、@ts-expect-error 和非空断言。

git diff -U0 HEAD -- '*.ts' '*.tsx' | grep '^+' | grep -E '\bas\b|@ts-ignore|@ts-expect-error|[]A-Za-z0-9_$)][!]([^=]|$)|["'\''"`][!]([^=]|$)' | sed 's/as const/__AS_CONST__/g'
git ls-files --others --exclude-standard -- '*.ts' '*.tsx' | tr '\n' '\0' | xargs -0 grep -nE '\bas\b|@ts-ignore|@ts-expect-error|[]A-Za-z0-9_$)][!]([^=]|$)|["'\''"`][!]([^=]|$)' | sed 's/as const/__AS_CONST__/g'

[!] 分组会匹配后缀断言:感叹号前是值字符、闭合引号、括号或圆括号,且后面没有等号。因此,value!、value!.x、value![0]、value!()、"value"! 和反引号括起来的接收者都会匹配;而 !=、!== 以及 !ready 这类前缀取反则不会匹配。末尾的 sed 只会将 as const 习惯用法替换为标记,而不是删除整行,因此同一行上同时出现的其他逃生口仍会保留。若某一行唯一的匹配项是 __AS_CONST__ 标记,则无需处理。

我会跳过 import { x as y } 这类导入别名。对于其余每个匹配项,我都会尝试通过正确的类型处理将其移除,也就是利用类型推断、缩小类型范围、类型守卫、泛型或通过 z.infer 从 schema 推导类型。每移除一项后,我都会重新运行检查;如果出现错误,就返回步骤 3。只有在确实无法避免时,才会保留逃生口,例如第三方库存在类型缺陷;并且必须附上一行注释,注明上游问题或类型缺陷。

步骤 6:汇报

检查通过后,我会简要汇报发现的错误数量、修复内容,以及仍然保留的逃生口(as 转型、@ts-ignore、@ts-expect-error 和非空断言),列出各自的数量,并为每个保留项附上一行说明理由。我的目标是 0。

循环中止条件

如果经过 3 轮修复与验证后错误仍然存在,我会停止操作并解释根本原因,列出剩余错误,说明问题可能出在文件本身还是依赖项中,并询问用户接下来如何处理。

重要规则

  • 如果错误来自共享工作区包中的错误类型,我会在该包中修复,并汇报后停止。
  • 我会检查错误出现在生成代码还是手写代码中。如果代码生成步骤已过期,我会建议运行相应命令,但不会执行。

评论

支持 Markdown