微软公司 TypeScript 高级产品经理 Daniel Rosenwasser 在与 The New Stack 的问答中分享了 TypeScript 在 2023 年取得的最重要的进展，并预告了开发人员在 2024 年的可以期待的内容。下面来看看本次问答的主要内容：

• 重点回顾：2023 年已发布装饰器、using、IDE 编辑体验、TypeChat 等功能。
• 优先考虑：2024 年优先考虑速度。
• 即将到来：最大的变化，隔离声明以支持并行构建。
• 准备迎接：TypeScript 5.5 弃用。
• 最需要的：无构建步骤。

Q1：您认为 2023 年 TypeScript 的最大变化是什么？

Rosenwasser：很难只选择一件事--我们一直在努力通过大大小小的方式让事情变得更好。但 2023 对我们来说意义重大。我们为 TypeScript 的精简和快速发展感到自豪，同时我们还带来了质量检查改进、期待已久的功能、ECMAScript 功能（其中一些是我们在 TC39 中倡导的），以及 Visual Studio 和 VS Code 中的编辑体验。

不得不说装饰器是最重要的变化之一。在此之前，TypeScript 采用的是旧的装饰器设计，但 5.0 版本为开发人员带来了新的标准化行为。在 5.2 版本中，我们实现了名为装饰器元数据的相关功能。装饰器是功能强大的构建模块，可以为类、方法、属性和参数添加元数据并修改行为。框架作者可以定义自己的装饰器供其他开发者使用。

我们还倡导并实施了 "using" 声明和显式资源管理。通过 "using" 声明，您可以声明一些变量，这些变量在超出范围时会被自动处置，从而确保即使出现异常也能释放资源。

我也非常喜欢我们对编辑体验所做的改进。我们现在提供了更多的自动补全功能，可以生成整个代码区域，我们在 JSX 标记中加入了链接游标，我们为内联变量提供了有用的新的重构工具，我们还使嵌套提示更加丰富，这样你就可以从中跳转到代码的不同部分。这些都是对编写和浏览代码的投入。

最后，我们很难忽视人工智能的最新发展。TypeChat 是我们几个人参与开发的一个实验性新库，旨在弥合 "松散" 或 "不精确" 的人工智能世界与非常精确的传统软件世界之间的鸿沟。这座桥梁建立在类型之上，而 TypeScript 的工作为我们提供了一个有用的视角。因此，虽然我们也在努力支持 Python 和 .NET，但我们希望 TypeChat 能让 TypeScript 开发人员更容易使用人工智能。

推荐阅读：TypeScript 5.3 正式发布

Q2：在 2024 年，TypeScript 的头号目标或首要任务是什么？

Rosenwasser：在过去的一年中，我们在 TypeScript 的性能方面取得了一些重大突破。其中一部分原因是大规模的重构使我们能够利用现代构建工具。还有一部分原因是找到了避免在类型检查器中工作的聪明方法。我们非常希望继续提升速度，并希望通过我们在性能测试基础设施方面的工作，可以深入研究并让 TypeScript 变得更快。

TypeScript 所关注的关键要素--使类型化 JavaScript 更具表现力、支持新的 ECMAScript 功能和强大的编辑器改进，这些要素将一直存在并不断向前发展。

Q3：开发者在接下来的一年中可以期待看到最重要的变化是什么？

Rosenwasser：我们在 TypeScript 中所做的很多工作都是为了长期发展，逐步打造更好的体验。不过，在大规模代码库方面，有一件事让我很兴奋。我们一直在与彭博社和谷歌的团队合作，以验证一种模式，在这种模式下，TypeScript 项目可以完全独立地进行类型检查，即使在依赖关系图中出现瓶颈时也是如此。这一概念被称为隔离声明发射（isolated declaration emit）。

作为背景介绍，TypeScript 有一种叫做 "声明文件" 的东西。它们就像头文件，对于描述未类型化的 JavaScript 代码很有用，但它们也是总结已经类型检查过的 TypeScript 文件的一种轻量级方法。声明文件的读取和处理量通常要小得多，因此在检查和构建项目时，TypeScript 可以为每个输入创建声明文件。

问题在于，TypeScript 会进行大量的类型推断，这意味着生成这些声明文件时需要对它们进行类型检查。但当你想根据依赖关系检查一个项目时，就必须对依赖关系进行完整的构建和类型检查。因此，隔离声明 emit 的理念是，模块 API 的每个 "公共" 部分都需要有类型注解。有了这个保证，就意味着 TypeScript 无需进行任何类型检查即可生成输出。协调器可以在所有项目中并行生成声明文件。这将释放各种生成声明文件的工具，甚至是开发人员一直在使用和喜爱的超快编译器和捆绑程序。

我们已经与 esbuild 和 Vite 等公司的开发人员进行了交流，他们都很想知道如何使用这种技术。几个月来，我们一直在与彭博社和谷歌公司的人员合作，他们正试图对此进行极限测试，到目前为止，我们对结果表示乐观！

Q4：开发者需要为此做好什么准备吗？如何准备？

Rosenwasser：随着新用户的加入，我们了解到学习 TypeScript 所面临的挑战。这促使我们重新思考如何在简化和保持兼容性之间取得平衡。

在 TypeScript 5.0 中，我们认为我们找到了一个很好的平衡点，开始舍弃那些在现代 JavaScript 工具中没有前途的标记。在 5.0 中，TypeScript 开始对一些很少使用的选项发布弃用警告，因为这些选项多年来一直没有太大意义。如果你已经升级到 TypeScript 5.0，使用这些选项就会出错，除非你使用 --ignoreDeprecations 标志。

到 TypeScript 5.5 时，用户将无法抑制这些错误。自 TypeScript 5.0 发布以来，我们还没有听到关于这些弃用的抱怨，这让我们感到欣慰。这意味着大多数开发人员不会遇到任何问题。

Q5：开发者最希望得到什么，他们可能会得到吗？有没有什么开发者希望但还需要等待一年？

Rosenwasser：我们听到开发者希望能够无缝地运行 TypeScript —— 如果可能的话，不需要构建步骤。为了实现这一目标，我们在类型注解提案中做了大量工作，但实现这一目标将是非常重要的一步。幸运的是，我们看到编译器和运行时都做了令人难以置信的工作，编译器可以像眨眼一样快地构建项目，以及可以原生运行 TypeScript 的运行时。事实上，在一些地方，TypeScript 已经非常容易运行，所以问题是：哪些地方没有？在 Node 中运行 TypeScript 会更容易吗？在 REPL（交互式解释执行）中运行 TypeScript 会更容易吗？我们希望找到一些更小的步骤，使运行TypeScript感觉更加透明。

当然，TypeScript 也是开放构建的。我们一直在寻求社区反馈，以了解开发人员在 TypeScript 体验中缺少什么，以及他们希望得到更多。