Deno 2020 年大事记

Deno 改变了开发者对包管理的看法。或许是广大开发者苦 npm 久矣，用法简单且高效的 Deno 收获了很多正向的反响。同时，Deno 也被评为 2020 年最佳开源。本文将带大家回顾一下 Deno 在过去的一年中都经历了哪些更新。

随着 API 的稳定化改造、若干大型基础架构的重构，以及诸多备受关注功能的开放，Deno 1.0 版本正式发布。2020 年，Deno 迎来了众多的挑战和变化。

1 月：再见 libdeno，你好 rusty_v8

libdeno 是一个 C++ 库，它可以更好地桥接 Deno 中的 V8 引擎和 Rust 代码，但缺点就是 libdeno 很难理解，也很难在其上开发更多额外的功能。基于这种情况，rusty_v8 应运而生。rusty_v8 发布于 2019 年秋季，是一个为 V8 引擎提供 API 的 Rust crate，同年 12 月，rusty_v8 就已经具备所有替换 libdeno 必需的 binding 条件。

2019 年底，替换 libdeno 的工作正式开始，当时 Deno 团队先用 rusty_v8 重写了一部分 libdeno，Deno 代码库中测试覆盖率不断提高，最终，libdeno 在 0.29.0 版本中被完全替换删除，此后 rusty_v8 也经历了绑定类型安全性相关的重要重构。

1 月版本更新

• 0.28.0

• 0.28.1

• 0.29.0

• 0.30.0

• 0.31.0

2 月：deno fmt 开始由 dprint 构建，deno test 子命令

2020 年 2 月，Deno 团队彻底重构了 deno fmt。此前，deno fmt 是一个简单的子命令，只是最终指向 prettier 的“deno run”的一个别名。这意味着在首次运行 deno fmt 以及每次 prettier 升级后，用户都必须下载 prettier 的最新版本。这和 Deno 承诺的内置工具开箱即用的原则很不契合。同时，prettier 真的很慢，而且存在很多性能方面的问题。

Deno 团队采用了 David Sherret 的 dprint 库，这是一个基于 Kang Dong Yun 的 SWC JavaScript 解析器、并由 Rust 编写的代码格式化工具。dprint 可以和 prettier 库一样的工作，但速度却比后者快了很多。于是，在经过一些测算后，Deno 团队决定在 deno fmt 中使用 dprint。

deno test 在首次运行命令时，也需要从标准库中下载模块。这导致添加了新的 Deno.test() API，并且 deno test CLI 子命令也让测试成为了 Deno 的一等公民。

2 月版本更新

• 0.32.0

• 0.33.0

• 0.34.0

• 0.35.0

3 月：V8 调试器、deno doc、deno upgrade

Deno 1.0 正式版发布最大的阻碍就是缺少 Chrome Devtools 的支持。因此，Deno 团队花了很多精力来增加对 V8 调试器的支持以及提高使用 Chrome Devtools 连接到 Deno 进程的能力。

在 3 月的更新中，CLI 中添加了两个新的子命令：

• deno doc

• deno upgrade

3 月同时也是构建过程发生巨大改进的一个月。此前，Deno 中的每一次构建都会导致 V8 从源码级别进行重新构建。众所周知，V8 是一个庞大的 C++ 项目，每次构建至少要花费 30 余分钟，虽然有大量的缓存和很多的技巧，但「费时」一直是 Deno 团队所面临的难题。现在，Deno 团队增加了 rusty_v8 的能力，使其在 GitHub 上生成和下载预构建过的静态库更加方便，从而使 Deno 的构建过程完全绕过 V8 的构建，这样不仅能够加快 CI 的构建，也能让贡献者可以更轻松地构建 Deno。

3 月版本更新

• 0.36.0

• 0.37.0

• 0.37.1

• 0.38.0

4 月：破坏所有 API 以构造更稳定的 API

4 月，Deno 团队在为 Deno 1.0 正式版发布做准备，他们将重点放在审阅 Deno global 全局中的 API。这也导致了诸多破坏性更新。对此，Deno 团队表示他们很谨慎，将所有不确定的 API 都移到了 --unstable 标志之后。

Deno 团队也对此作出了 1.0 版本的重要承诺：在 Deno 2.0 版本发布之前，已标记为稳定的 Deno API 将不会做任何破坏性更新。

4 月是 Deno 版本以 0.x.y 命名的最后一月。

4 月版本更新

• 0.39.0

• 0.40.0

• 0.41.0

• 0.42.0

5 月：Deno 1.0 正式发布

5 月初，Deno 标记删除了以下几个功能：

• JSON imports

• WASM imports

• window.location API

• Rust API for deno crate

Deno 团队表示，删除的原因是因为他们不想 JSON/WASM imports 缺少底层规范支持，或者 deno crate 下有 Rust API 额外维护负担的情况下提供相关 API。

Ryan 发表 Deno 演讲的整整两年后，Deno 1.0 正式于 2020 年 5 月 13 日发布。

Deno 一经发布，便收到了广大开发者的欢迎，同时也收获了大量的新用户和新贡献者。Deno 1.0 发布后，Deno 团队也没有松懈，他们继续开始回到了有关运行时重要组件的工作中：他们用 SWC 重写了 TypeScript 宿主中的依赖关系分析，这一改动也标志着 Deno 团队开始着手使用 Rust 来重写 TypeScript 基础架构的一部分。

5 月版本更新

• 1.0.0-rc1

• 1.0.0-rc2

• 1.0.0-rc3

• 1.0.0

• 1.0.1

• 1.0.2

• 1.0.3

6 月：增量类型检查和 deno lint

Deno 1.0 发布后，社区中反馈最多的问题之一就是 TypeScript 的编译和类型检查非常慢。于是，Deno 团队开始着手改进 TSC 集成来支持增量类型检查。经过多次反复试验的 PR，Deno 团队使其功能能够正常使用，并且显著地改进了开发效率。尽管通过利用 TSC 的增量 API 设法提高了类型检查的速度，但仍需要依靠它来 emit 已转义的源。

TypeScript 的伟大设计原则之一是它只是一个具有附加语法的 JavaScript，因此剥离类型信息（转换为 JavaScript）是相对容易的操作。于是，Deno 团队设定了能够在 Rust 中使用 SWC 进行转移的同时还能继续使用 TSC 进行类型检查的目标。

除此之外，本月还加入了 deno lint。经过几个月的开发，Deno 团队在一个单独的仓库中添加了新的 deno lint 子命令。这是另一个建立在 SWC JavaScript 解析器上的项目。

6 月版本更新

• 1.0.4

• 1.0.5

• 1.1.0

• 1.1.1

• 1.1.2

7 月：将内部运行时代码从 TypeScript 转换为 JavaScript

2020 年 7 月，Deno 团队宣布将内部运行时代码从 TypeScript 转换为 JavaScript。主要有几个因素：Deno 内部运行时代码的每个构建过程中，类型检查和快照前绑定等都是复杂且缓慢的构建步骤。Deno 有两个独立的 TypeScript 编译器宿主，一个是只用于构建过程的 deno_typescript crate，另一个则被包含在 Deno 的二进制文件中。此外，整个构建过程中将会产生 2 分钟的增量重建。而使用 JavaScript，Deno 能极大地简化内部构建依赖关系和总体复杂性，因为 JavaScript 代码是由 TypeScript 编译器作为单个文件包生成的，从而导致 Deno 团队无法控制输出代码的类型。ES 模块进行了转换，变为使用 bundle 的 SystemJS 加载程序，这为最终 bundle 添加了大量的代码。

《Deno 将停止使用 TypeScript，并公布五项具体理由》

不过，Deno 将只在内部的 Deno 代码中停用 TypeScript，而 Deno 用户代码中的 TypeScript 部分将依旧保留，检查类型自然也会一同存在。

7 月版本更新

• 1.1.3

• 1.2.0

• 1.2.1

• 1.2.2

8 月：新的镜像源网站发布

原文章：《Updates to deno.land/x》

2020 年 8 月 3 日，Deno 团队发布了全新的 deno.land/x 镜像源，可以通过 WebHooks 与 GitHub 集成。每当一个模块被更新，Deno 的系统会下载并永久保存其源代码，这样就可以依赖不可变的源代码链接。

由于正在使用 Deno 基础结构进行一些非公开工作，Deno 团队开始努力将 Deno 系统分为更小的“op crates”，以便可以生成定制的 V8 运行时。在 2020 年 8 月，Deno 团队正式迈出了第一步，发布了 deno_web crate，它提供了一些基本的 Web API，例如 Event、TextUncoder 和 TextDecoder。

同时，基准系统使用了 Rust 来重写，这也意味着 Deno 团队开始着手减少 Deno 项目的构建依赖性。

8 月版本更新

• 1.2.3

• 1.3.0

• 1.3.1

• 1.3.2

9 月：WebSocket API、控制台中的 CSS 样式、文件监听和测试覆盖

2020 年 9 月，Deno 发布了自 1.0 版本以来最大的功能版本。更多详细信息可参见 1.4.0 版本的文档：

https://deno.land/posts/v1.4

此外，在维护方面也有一个重大变化：发布计划正式更改。新版本更新将从每月发布一次改为每六周发布一次，以和 Rust 和 Chrome 项目相匹配。

9 月版本更新

• 1.3.3

• 1.4.0

• 1.4.1

• 1.4.2

10 月：REPL 改造、捆绑改进和默认 isolatedModules

2020 年 10 月，Deno 1.5.0 正式发布，文档地址为：

https://deno.land/posts/v1.5

本月最大的变化是在 TypeScript 编译器宿主中默认启用 isolatedModules 选项。这一设置可以确保每个文件都可以由 TSC 以外的工具（例如 SWC 和 Babel）隔离编译（不需要知道其类型或其他模块）。这一变化对模块生态系统产生了重大影响，一度使很多模块无法使用，直至支持 isolatedModules。

本月还在 SWC 中采用了新的 bundle 特性，这是对原始 TypeScript 编译器转向使用 Rust 方向的又一步迈进。

10 月版本更新

• 1.4.3

• 1.4.4

• 1.4.5

• 1.4.6

• 1.5.0

• 1.5.1

11 月：对 TSC 编译器基础架构的全面重写

Deno 团队的 Kitson Kelly 用了数周的时间重写了编译管道（compilation pipeline）的总结，同时也进一步提高了 TypeScript 的编译速度，更重要的是还清了大量的技术债。

添加了 deno_crypto op crate。

11 月版本更新

• 1.5.2

• 1.5.3

• 1.5.4

12 月：构建自包含的二进制文件以及 deno lsp

《Deno 1.6 正式发布！支持将 TypeScript 编译成单个可执行文件，苹果 M1 可原生运行》

2020 年 12 月，Deno 1.6 正式发布，其中包含了两个里程碑式的特性：

• 构建自包含的独立二进制文件

• 内置的 Deno 语言服务器

Demo compile 是 Deno 的 bug 追踪器中最受期待的特性之一。

通过提供内置语言服务器，Deno 1.6 提高了所有能够使用 LSP 协议的编辑器的开发体验，它导致了对 vscode_deno 的第三次翻新，此项工作目前还在进行中。

12 月版本更新

• 1.6.0

• 1.6.1

• 1.6.2

• 1.6.3

展望 2021

回顾整个 2020 年，Deno 的项目和社区都有很大的增长。2021 年，期待 Deno 会有更好的发展。

如果你有兴趣成为 Deno 的贡献者，或是想了解 Deno 的进展，可以通过下方地址查看更多信息。

Deno 问卷调查：

https://forms.gle/hbhP46LUAfVFMggU6

2021 年第一季度路线图：

https://github.com/denoland/deno/issues/8824

通过添加新的语言服务器功能来提高对 IDE 的支持：

https://github.com/denoland/deno/issues/8643

使用 Web 平台测试套件来确保对 Web 的兼容性：

https://github.com/denoland/deno/issues/9001