关于 fix-ts-errors
fix-ts-errors 是在错误源头修复 TypeScript 类型问题的技能,并反复运行工作区类型检查直至通过。它会追踪类型变更在工作区中的影响,并在报告前审查绕过类型检查的写法。
主要功能
- 01运行工作区类型检查
- 02从源头修复错误
- 03追踪跨包错误影响
- 04审查类型检查逃逸写法
- 05多轮失败后停止并说明
适用场景
- 01修复变更文件中的 TypeScript 错误
- 02纠正共享包的类型定义
- 03检查类型变更对导入方的影响
- 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 轮修复与验证后错误仍然存在,我会停止操作并解释根本原因,列出剩余错误,说明问题可能出在文件本身还是依赖项中,并询问用户接下来如何处理。
重要规则
- 如果错误来自共享工作区包中的错误类型,我会在该包中修复,并汇报后停止。
- 我会检查错误出现在生成代码还是手写代码中。如果代码生成步骤已过期,我会建议运行相应命令,但不会执行。