TypeScript被吹过头了？

作者丨 Paul Cowan

译者丨王强

策划丨小智

2019 年以来，越来越多的知名前端开源项目选择使用 TypeScript 作为其新版本的开发语言，TypeScript 的社区支持也日趋完善，VS Code + TypeScript 的组合拳让不少原本持怀疑，甚至抵制态度的前端开发者们不禁喊出“真香！”另一方面，TypeScript 也还存在一些各种各样的问题，本文作者是其忠实粉丝，他在日常使用中指出了这些较为严重的问题。

开始看本文之前，我希望读者朋友们知道我在很大程度上是一位 TypeScript 粉丝。在我的前端 React 项目和各种后端 Node 工作里，所使用的主要编程语言都是 TypeScript。我是这条船上的人，但也确实有一些疑惑，想在这篇文章中讨论一下。到目前为止，我已经使用 TypeScript 写了至少三年的代码，涉及的项目不计其数，因此可以说 TypeScript 的确是走在了正路上，或者说满足了某种需求。

TypeScript 克服了一些难以逾越的障碍，成为了前端编程领域的主流之选。TypeScript 在这篇文章（https://www.agiratech.com/most-in-demand-programming-languages-learn-2020/）列出的最受欢迎编程语言中排名第七。

无论你是否在使用 TypeScript，不管多大规模的软件团队都应遵循以下实践：

精心编写的单元测试应在合理范围内覆盖尽可能多的生产代码；
结对编程——另一双眼睛可以捕捉到的远不止语法错误；
良好的同行评审流程——正确的同行评审可以找出许多机器无法捕获的错误；
使用 eslint 之类的 linter。

TypeScript 可以在这些基础之上增加额外的一层安全性，但我认为这在编程语言的需求列表中是排在非常靠后的位置上的。

TypeScript 并非健全的类型系统

我认为这可能是 TypeScript 当前版本面临的主要问题，但首先，我来定义一下什么是健全（sound）和不健全（unsound）的类型系统。

健全

一个健全的类型系统能确保你的程序不会进入无效状态。例如，如果一个表达式的静态类型是 string，则在运行时，对它求值时你肯定只会得到一个 string。

在健全的类型系统中，永远不会在编译时 或运行时 出现表达式与预期类型不匹配的情况。

当然，健全性（soundness） 也是有级别的，具体含义可以斟酌。TypeScript 具有一定程度的健全性，并会捕获以下类型的错误：

// 类型 'string' 不能赋值给 类型 'number'
const increment = (i: number): number => { return i + "1"; }

// 类型 '"98765432"' 的参数不能赋值给类型 'number' 的参数.
const countdown: number = increment("98765432");

不健全

关于 Typescript，以下事实是非常明确的：100％的健全性不是它的目标，并且 TypeScript 的非目标列表（https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals）中的 3 号非目标明确指出：

应用一个健全或“正确无误”的类型系统（不是我们的目标）。相反，要在正确性和生产力之间取得平衡。

这意味着不能保证变量在运行时具有定义的类型。我可以用下面一些人为的例子说明这一点：

interface A {
    x: number;
}

let a: A = {x: 3}
let b: {x: number | string} = a;
b.x = "unsound";
let x: number = a.x; // 不健全

a.x.toFixed(0); // 这啥？

上面的代码是不正确的，因为从 A 接口中可知 a.x 应该是一个数字。不幸的是，经过一些重新赋值后，它最终以一个字符串的形式出现，并且后面的代码能通过编译，但会在运行时出错。很不幸，这里显示的表达式可以正确编译：

a.x.toFixed(0);

我认为这可能是 TypeScript 的最大问题，那就是健全性不是它的目标。我仍会遇到许多运行时错误，这些错误没有被 tsc 编译器标记出来，但如果 TypeScript 有一个健全的系统就能做到了。采用这种方法，意味着 TypeScript 在健全和不健全的阵营之间是在脚踩两只船。这种摇摆路线遇上 any 类型就更严重了，我将在后文提到这一点。我还是得编写尽可能多的测试，这让我感到沮丧不已。当我第一次开始使用 TypeScript 时，我错误地得出了一个结论，以为以后就用不着编写这么多单元测试了。

TypeScript 挑战了现状，声称降低用户使用类型的认知开销比类型健全更重要。

我理解为什么 TypesScript 会走这条路，并且有一个观点指出，如果类型系统的健全性得到 100％保证，那么 TypeScript 的采用率就不会那么高了。随着 dart 语言逐渐流行（因为 Flutter 现已广泛应用），这个看法也被证伪了。健全性是 dart 语言的一个目标，可以参考这里的讨论：

https://dart.dev/guides/language/sound-dart

TypeScript 的不健全性，以及它在严格的类型系统上开的一大堆天窗拖累了它的效率，让它在今天处于相当鸡肋的位置上，非常可惜。我的愿望是，随着 TypeScript 的流行，会有更多的编译器选项可供使用，从而使高级用户可以争取 100％的健全性。

TypeScript 不保证任何运行时类型检查

运行时类型检查不是 TypeScript 的目标之一，因此这种愿望可能永远不会实现。例如，在处理从 API 调用返回的 JSON 负载时，运行时类型检查会很有用。如果我们可以在类型级别上控制它，就用不着一整筐错误和许多单元测试了。

我们无法在运行时保证任何事情，因此可能会出现以下情况：

const getFullName = async (): string => {
  const person: AxiosResponse = await api();

  //response.name.fullName 可能在运行时成为 undefined
  return response.name.fullName
}

有一些支持这种需求的库，例如 io-ts；虽然它很棒，但可能意味着你必须复制你的模型。

可怕的 any 类型和严格选项

any 类型就是字面意思，编译器允许任何操作或赋值。

TypeScript 往往在小事上表现很不错，但是人们习惯给花费时间超过 1 分钟的任何事物都来个 any 类型。我最近在一个 Angular 项目中工作，看到很多这样的代码：

export class Person {
 public _id: any;
 public name: any;
 public icon: any;

TypeScript 会让你忘掉类型系统。你可以用一个 any 把所有事物的类型干掉：

("oh my goodness" as any).ToFixed(1); // 记得我提到健全性时说的话吗？

strict 编译器选项会启用以下编译器设置，这些设置会让事物看起来更健全：

--strictNullChecks
--noImplicitAny
--noImplicitThis
--alwaysStrict

还有 eslint 规则 @typescript-eslint/no-explicit-any：

https://github.com/typescript-eslint/typescript-eslint/blob/master/packages/eslint-plugin/docs/rules/no-explicit-any.md

any 的扩散会毁掉你类型系统的健全性。

结论

我必须重申一点，我是 TypeScript 粉丝，也在日常工作中使用它，但我确实认为它有很多缺陷，而且炒作有些过头了。Airbnb 声称 TypeScript 可以阻止 38％的错误。我非常怀疑这一精确的百分比数字。TypeScript 不会给已有的良好实践锦上添花。我还是得编写尽可能多的测试。你可能不相信，我编写的代码变多了，可能还得编写许多类型测试。我仍然会遇到意外的运行时错误。

TypeScript 提供了比较基础的类型检查，但健全性和运行时类型检查不是它的目标，这让 TypeScript 处于脚踩两条船的状态，一只脚踏上了更好的那艘，一只脚还呆在现在的破船上，真是不幸。

TypeScript 的亮点在于良好的 IDE 支持，比如说 vscode 里如果我们打错什么内容，就会获得视觉反馈。