这很酷，我也想看到同样的按国家/地区划分的数据，例如 tsc --upgrade-flag strictFunctionTypes example.ts

如果我们认为这是可能的并且有用的，我们确实为编辑器构建了这些类型的快速修复(尽管我们仍然没有一个可以从命令行运行修复的工具@DanielRosenwasser )。我们只是不总是费心去麻烦 - unknown 默认更改只需要在DT更新时大约20个包(每个包在一个或两个地方，实际上在一些情况下指出了一个未处理的空/未定义的错误),所以看起来并不那么糟糕。

我想说的是：我认为#13195需要自动化迁移。然而，与该问题相关的还有其他多个阻塞功能。

Should I close this issue, given that this sort of thing is in the works already per Wes' comment? #33345 (comment)

我的意思是，我会把这个问题留给@DanielRosenwasser,因为他一直在寻找一个理由来构建命令行上的快速修复功能。

大致上有两种不同类型的错误需要考虑：

• 根本原因可以通过类型系统轻易识别的错误(类型I)
• 根本原因无法通过类型系统轻易识别的错误(类型II)

一个类型I错误的示例是 strictClassPropertyInitialization - 通过错误本身的结构，TS可以轻松地识别出“我正在发出一个错误，原因是添加了一个以破坏性方式进行修改的规则”。
一个类型II错误的示例是在 #33272 中识别出的 Set 构造函数更改 - 这是由于推理规则中的微妙变化引起的，而代码中稍后发生的确切错误并不是TS可以合理地追溯到行为更改的原因。
我们可以为类型I错误创建快速修复程序，通常也会这样做。这些修复程序也往往具有很好的文档记录和经过深思熟虑的更改，因为它们通常是“我们故意破坏你”的那种破坏性更改。许多类型I错误还与关闭它们的命令行标志相关联。
对于类型II错误，即使我们能弄清楚发生了什么，通常也没有“快速修复”，因为它取决于代码最初试图做什么，而需要发生的更改可能在第一个实际类型错误发出的地方非常词汇上远离。
我们可以整天提供针对类型I错误的工具，但我认为这是一种低价值活动。这些错误通常并不特别痛苦，提前得到很好的信号，通常有一个简单的命令行修复或可以通过足够聪明的正则表达式批量解决。采用类似Facebook的 codemod 工具为这些修复提供CLI体验可能是值得考虑的事情。
类型II错误令人烦恼。我们甚至可能根本不知道自己正在制造它们 - filter(Boolean) 再次来自 #33272 就是个例子。即使我们完全意识到这将是一个破坏性更改，也不清楚我们会怎么做。没有明显的快速修复来发布“这个表达式将以一种可能会破坏下游代码的方式改变为更准确的类型，从而可能破坏做出某些其他假设的代码”的错误。
例如，假设您编写了一些代码

const arr = [1, 2, 3, "four", "five"];
const arr2 = arr.filter(x => +x === x);
arr2.push("six");

也许将来，TS变得更聪明，说 +x === x 是 x is number 的类型保护表达式，并且通过识别 array.filter(type guard function) 返回更具体的数组类型变得更聪明。乍一看，这不是一个破坏性更改...但是它是：arr2.push("ok") 行现在是一个错误，因为 arr.filter 返回了 number[] 而不是 (string | number)[] 。
即使是最简单的例子，错误与原始更改之间的因果关系也非常脱节，甚至不清楚发布正确的“修复”是什么。
对于类型II错误，似乎您只需要一个运行 tsc 的工具，接收错误并插入Assert或 // @ts-ignore 注解即可。例如，根据错误的密度，我可能会有以下两种输出之一：

const arr = [1, 2, 3, "four", "five"];
const arr2 = arr.filter(x => +x === x);
// @ts-ignore Error 'cannot convert "six" to 'number'" introduced in TS 4.2
arr2.push("six");

vs

const arr = [1, 2, 3, "four", "five"];
// TODO: Multiple errors involving 'arr2' introduced in TS 4.2
const arr2: any = arr.filter(x => +x === x);
arr2.push("six");
arr2.push("seven");
arr2.push("eight");

我们可以整天为类型I断点提供工具，但我认为这是一项低价值活动。这些断点通常并不特别痛苦，提前得到很好的信号，通常可以通过简单的命令行修复或足够聪明的正则表达式批量解决。

我认为快速修复，在很多时候，往往是相当低投入的，并有助于更多地教育用户关于断点本身以及如何修复它们。所以我不认为它是低价值的，即使它是，最初的努力也不是不合理的。