跳到主要内容

2020 年的 Deno

凭借 API 稳定化、多次大型基础设施重构、1.0 版本发布以及交付最受期待的功能,2020 年为 Deno 项目带来了许多进展。

请填写 Deno 调查问卷,以帮助指导我们 2021 年的开发工作。

继续阅读以了解 Deno 的年度回顾。

一月:告别 libdeno,欢迎 rusty_v8

libdeno 是一个 C++ 库,它促进了 Deno 中 V8 引擎和 Rust 代码之间的接口。该库难以理解和开发额外的功能。这种情况导致了 rusty_v8 在 2019 年秋季的诞生。rusty_v8 是一个 Rust crate,它为 V8 引擎提供 API。到 12 月,rusty_v8 已经拥有替换 libdeno 所需的所有绑定。这项工作始于 2019 年底,当时 libdeno 的第一部分使用 rusty_v8 进行了重写。由于 Deno 代码库中不断增长的测试覆盖率,我们有信心继续前进,并在两周内完成了这项工作。libdeno 在 0.29.0 版本中被完全移除,从那时起,rusty_v8 经历了对其绑定类型安全性的重大重构。

该月发布的版本

二月:deno fmt 现在使用 dprint,deno test 子命令

本月我们彻底改变了 deno fmt。在此之前,deno fmt 只是一个简单的子命令,其底层只是指向 prettier 的 “deno run” 的别名。这意味着在第一次运行 deno fmt 以及每次升级后,用户都必须下载最新版本的 prettier 模块。这种情况感觉不太对劲,因为 Deno 承诺开箱即用地提供这些工具。prettier 也相当慢,性能有待提高。

我们通过 David Sherret 了解了 dprint,这是一个用 Rust 编写的代码格式化程序,它基于 Kang Dong Yun 的 SWC JavaScript 解析器。dprint 可以像 prettier 模块一样格式化代码,但速度要快几个数量级。经过一些初步测试,我们决定在 deno fmt 中使用 dprint

deno test 也有相同的要求,即在首次运行时从标准库下载模块。这促使我们添加了一个新的 Deno.test() API 和 deno test CLI 子命令,这使得在 Deno 中进行测试成为一等公民。

该月发布的版本

三月:V8 调试器,deno doc,deno upgrade

缺少 Chrome Devtools 支持是 1.0 版本发布的主要障碍。我们花费了大量精力来添加对 V8 调试器的支持,以及使用 Chrome Devtools 连接到 Deno 进程的能力。

CLI 中添加了两个新的子命令

  • deno doc
  • deno upgrade

我们还看到了构建过程的巨大改进。在此之前,每次构建 Deno 时,V8 都是从源代码构建的。V8 是一个庞大的 C++ 项目,很容易需要 30 多分钟才能构建完成。尽管有很多构建缓存和其他技巧,但这仍然是我们不断需要应对的难题。我们为 rusty_v8 添加了在 Github 发布版本上生成和下载预构建静态库的能力,从而允许 Deno 构建完全绕过 V8 构建。这简化并加快了 CI 中的构建速度,但最重要的是使贡献者更容易构建 Deno。

该月发布的版本

四月:为了盛大的稳定化,打破所有 API

本月花在了审查 Deno 全局中的 API 上,为 1.0 版本发布做准备。这导致了许多破坏性更改。我们很保守,因此任何我们不确定的 API 都被移到了 `--unstable` 标志后面。

这是 1.0 版本发布的主要承诺;标记为稳定的 Deno API 在 2.0 版本发布之前不会有破坏性更改。

本月标志着 Deno 的最后一个 0.x.y 版本发布。

该月发布的版本

五月:Deno 1.0 发布

本月初标志着移除各种功能

  • JSON 导入
  • WASM 导入
  • window.location API
  • deno crate 的 Rust API

移除的原因是我们不想承诺以当前形式支持 API,原因在于:JSON/WASM 导入缺乏底层规范;或者 deno crate 的 Rust API 带来额外的维护负担。

最终在 5 月 13 日,恰好在 Ryan 最初的 Deno 演示 两年后,我们发布了 1.0 版本。

在社交媒体上,该版本的发布受到了非常好的欢迎。我们的博客文章被广泛分享,我们获得了许多新用户和贡献者。

但尘埃尚未落定,我们就重新开始研究运行时的另一个主要组件:TypeScript 主机中的依赖分析已使用 SWC 重写。此更改标志着开始努力用 Rust 重写我们 TypeScript 基础设施的部分内容。

该月发布的版本

六月:增量类型检查和 deno lint

1.0 版本发布后,社区收到的主要抱怨之一是 TypeScript 编译和类型检查非常慢。因此,我们将目光投向改进 TSC 集成以支持增量类型检查。经过几次试错 PR,我们能够使功能正常工作,并显着缩短开发循环时间。即使我们设法通过利用 TSC 的增量 API 提高了类型检查速度,我们仍然依赖它来发出转译后的源代码。TypeScript 的伟大设计原则之一是它只是带有附加语法的 JavaScript,因此剥离类型信息(转译为 JavaScript)是一个相对容易的操作。因此,我们设定了目标,即能够使用 Rust 中的 SWC 进行转译,同时继续使用 TSC 进行类型检查。

经过几个月在幕后、在一个单独的存储库中的开发,添加了一个新的 deno lint 子命令。这是又一个构建在 SWC JavaScript 解析器之上的项目。

该月发布的版本

七月:将内部运行时代码从 TypeScript 转换为 JavaScript

本月,我们做出了一个艰难的决定,将我们的内部运行时代码从 TypeScript 转换为 JavaScript。导致我们做出此决定的因素有以下几个:每次构建 Deno 内部运行时代码时,构建过程都复杂且缓慢,在进行 快照之前,代码需要进行类型检查和捆绑。我们有两个独立的 TypeScript 编译器主机实现。一个仅用于构建步骤,称为 deno_typescript crate。另一个包含在 deno 二进制文件中。此外,整个过程对构建时间产生了重大影响:增量重建需要 2 分钟!通过使用纯旧 JavaScript,我们能够极大地简化内部构建依赖项和整体复杂性。由于实际的 JavaScript 代码是由 TypeScript 编译器作为单个文件捆绑包生成的,因此我们对输出代码的外观几乎没有控制权。ES 模块被转换为在捆绑包中使用 SystemJS 加载器,这为最终捆绑包添加了大量代码。

该月发布的版本

八月:发布新的注册表

原始帖子: https://deno.org.cn/blog/registry2

8 月 3 日,我们发布了一个新的 deno.land/x 注册表,该注册表使用 Webhooks 与 GitHub 集成。当模块更新时,我们的系统会下载并永久保存源代码,以便我们可以依赖不可变的源代码链接。

由于正在进行一些非公开的工作以使用 Deno 基础设施,我们开始努力将 Deno 系统分解为更小的 “op crates”,这些 crates 可以混合和匹配以生成自定义 V8 运行时。8 月份朝着这个方向迈出了第一步,并发布了 deno_web crate,提供了一些基本的 Web API,如 EventTextEncoderTextDecoder

本月,基准测试系统用 Rust 重写;这标志着开始了减少 Deno 项目构建依赖项数量的艰苦努力。

该月发布的版本

九月:WebSocket API,控制台中的 CSS 样式,文件监视器,测试覆盖率

本月,我们发布了自 1.0 以来最大的功能版本。更多详细信息请参见 1.4.0 博客文章

项目的维护部分发生了另一个重要的变化。发布计划从每月发布小版本更改为每六周发布新的小版本,与 Rust 和 Chrome 项目保持一致。

该月发布的版本

十月:REPL 改造,改进的捆绑,默认启用 isolatedModules

1.5.0 博客文章

本月发生的最大变化是默认在 TypeScript 编译器主机中启用 isolatedModules 选项。此设置更改了 TypeScript 的行为方式,确保每个文件都可以由 TSC 以外的工具(如 SWC 和 Babel)隔离转译(无需了解类型和/或其他模块)。此更改对模块生态系统产生了重大影响,导致某些流行的模块无法使用,直到维护人员调整代码以使用 isolatedModules

本月,我们还在 SWC 中采用了新的捆绑功能,这是朝着使用 Rust 而不是原始 TypeScript 编译器的方向迈出的又一步。

该月发布的版本

十一月:TSC 编译器基础设施的大规模重写

本月,我们看到了 Kitson Kelly 长达数周的重写编译管道项目的完成。它进一步提高了 TypeScript 转译的速度,但最重要的是偿还了大量技术债务。

添加了 deno_crypto op crate

该月发布的版本 1.5.2, 1.5.3, 1.5.4

十二月:自包含二进制文件和 LSP

1.6.0 博客文章

在 12 月,我们发布了 1.6 版本,其中包含两个里程碑式的功能:自包含二进制文件和语言服务器。deno compile 是 Deno 错误跟踪器中最受期待的功能。

提供内置语言服务器可以为所有可以进行 LSP 协议通信的编辑器提供出色的开发体验。这导致了 vscode_code 的第三次改造,目前仍在进行中。

该月发布的版本

2021

2020 年,我们看到了项目和社区的巨大增长。展望 2021 年,我们对 Deno 背后的势头充满信心。敬请期待即将发布的一些激动人心的公告!

如果您有兴趣为 Deno 做出贡献,或者只是想关注我们的进展,请查看以下内容