TypeScript 官方：JavaScript 中直接支持类型！

2023-05-08 108

版权

本文内容由阿里云实名注册用户自发贡献，版权归原作者所有，阿里云开发者社区不拥有其著作权，亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容，填写侵权投诉表单进行举报，一经查实，本社区将立刻删除涉嫌侵权内容。

简介： 大家好，我是 ssh。TypeScript 团队在深夜突然发了一条推，神秘兮兮说：“如果我们可以直接在 JavaScript 中支持类型，会怎么样？”。

大家好，我是 ssh。TypeScript 团队在深夜突然发了一条推，神秘兮兮说：“如果我们可以直接在 JavaScript 中支持类型，会怎么样？”。

他们在评论区说：“类型作为注释”的提案意味着浏览器可以直接运行通过了 TS 检查的代码(即使它们没有做任何类型检查)。这意味着更好的编辑体验和更快的迭代。

这是一个很让人兴奋的想法，接下来我们具体看看这个提案的内容。

这是一个新的 stage0 的语法提案，暂时还未提交给 TC39。github 的仓库地址是 https://github.com/giltayar/proposal-types-as-comments

背景

我们团队最近在 JavaScript 领域看到的一个趋势是，需要更快的迭代时间和减少构建步骤。换句话说，“更快、更简单”。

在某种程度上，这已经发生了。多亏了浏览器的成功，开发人员通常可以避免编译较新版本的JavaScript以在较旧的 runtime上运行。在某种程度上，构建也是如此 —— 大多数浏览器都内置了对 module 的支持，因此构建渐渐成为了一个优化步骤而不是必要步骤。这种情况下，TypeScript 如何跟进呢？

如果我们回到2012年，TypeScript首次发布的时候，JavaScript的世界就大不相同了！一些浏览器经常更新，但另一些不会。我们还不清楚Internet Explorer的古老版本会持续多久，这导致构建工具和编译器等工具大行其道。在向JavaScript添加构建步骤的时代，TypeScript能够蓬勃发展——毕竟，如果你需要编译JavaScript，为什么不也顺便编译你的类型呢？但是，如果我们上面提到的这些趋势继续发展，编译类型可能是编写 TypeScript 代码到运行之间的唯一步骤，我们不想成为阻碍良好开发体验的人！

在某些方面，我们的 JavaScript 支持弥补了这一差距，如果您使用像Visual Studio或Visual Studio Code这样的编辑器，可能已经见过 JSDoc 形式添加类型注释：

/**
 * @param a {number}
 * @param b {number}
 */
function add(a, b) {
    return a + b;
}

因为这些只是注释，它们根本不会改变代码的运行方式——它们只是一种文档形式，但TypeScript利用了它们，通过代码补全、自动重构等方式为您提供更好的JavaScript编辑体验。甚至可以通过在文件顶部添加 // @ts check注释来添加类型检查^[1]，或者通过TypeScript编译器，开启 checkJs 选项来运行这些文件。这个特性使得在不需要构建步骤的情况下就可以获得一部分的TypeScript体验，您可以将其用于小型的脚本、基本网页和 Node.js服务端代码等等。

不过，您会注意到这有点冗长，失去了 TypeScript 写类型的简洁性。

如果我们全都要呢？

如果我们可以有一些像TypeScript这样的语法，但在JavaScript中完全被忽略——有点像注释。

function add(a: number, b: number) {
    return a + b;
}

我们的团队相信这里有很大的潜力，本月我们希望将其作为提案提交^[2]给ECMAScript标准委员会TC39！

如何工作？

当我们被问到“JavaScript什么时候能拥有类型？”，我们回答的很犹豫。在过去，如果你问开发人员他们对JavaScript中的类型有什么想法，你会得到很多不同的答案。一些人认为类型应该被完全忽略，而另一些人则认为它们应该具有某种意义——可能是它们应该执行某种运行时验证，或者它们应该作为引擎优化的提示等等。但在过去几年里，我们看到人们更倾向于一种与TypeScript的发展方向一致的设计，即类型在运行时被完全忽略且可擦除。现在我们可以自信的提出“类型作为注释”的提案了。

这个提案的想法是^[3]，可以开创一组语法，JavaScript 完全忽视它，但TypeScript、Flow等工具可以使用这些语法。这使我们能够保留您喜欢的TypeScript里的内容——它的类型检查和编辑体验，同时消除开发中需要的构建步骤。

因此，在编写和运行代码时，工具链看起来会有些不同。

与此同时，编写代码和类型检查将保持不变。开发人员可以在支持TypeScript的编辑器中获得即时类型检查反馈，在命令行里运行TypeScript，将TypeScript添加到CI任务中。最大的区别是，因为我们不需要构建步骤，所以我们将大大降低JavaScript开发人员的入门门槛，让他们体验类型和优秀工具的强大功能。

要实现这一点，JavaScript只需为变量和函数上的类型注释、可选性修饰符（?）等添加语法对于参数和类成员、类型声明（interface和type别名）和类型断言运算符（as和!）——所有这些都不会影响周围代码的运行方式。

同时也支持可见性修饰符（例如public、private和protected）；然而， enum、namespace将参数属性不在本提案的范围内，因为它们具有可见的运行时行为。根据反馈，这些特性可以作为单独的ECMAScript特性提出，但我们当前的目标是支持TypeScript的一些大子集，我们认为这可能是JavaScript的一个很有价值的补充。

通过这一突破，我们为类型检查器提供了创新的空间。这确实意味着引擎会很顺利地运行代码，但我们相信类型检查器可以（也应该）是规范性的，并实施比运行时更严格的约束。结合起来，这就形成了一种类型语法，可以跨不同的检查器进行定制，或者如果有人认为他们对TypeScript或任何其他类型检查器不满意，也可以删除掉。