迪恩2020

＆lt;-其他新闻GitHub凭借API的稳定功能，几个大型基础结构重构，1.0版本以及最受要求的单个功能，2020年为Deno项目带来了很多影响。

libdeno是一个C ++库，可促进V8引擎与Deno中的Rust代码之间的接口。该库很难推理和开发其他功能。这种情况导致rusty_v8于2019年秋季诞生。rusty_v8是一个Rust板条箱，为V8引擎提供API。到了12月，rusty_v8具备了所有必需的绑定来替换libdeno。这项工作始于2019年底，当时使用rusty_v8重写了libdeno的第一部分。由于Deno代码库中不断增长的测试覆盖率，我们有信心继续前进，并在两周内完成了工作。 libdeno在0.29.0版中已完全删除，此后rusty_v8经历了主要的绑定类型安全性重构。

这个月我们彻底改变了deno fmt。到目前为止，deno fmt是asimple子命令，它在幕后只是＆quot; deno run＆＃34;的别名。指向更漂亮。这意味着在首次运行deno fmt和每次升级后，用户必须下载最新版本的漂亮模块。由于Deno承诺提供现成的工具，因此这种情况并不正确。更漂亮的速度也很慢，而且性能让人不敢恭维。

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

deno test在首次运行时具有从标准库下载模块的相同要求。这导致添加了新的Deno.test（）API和deno test CLI子命令，该命令在Deno一流公民中进行了测试。

缺少Chrome Devtools支持是1.0版本的主要障碍。花了很多心血来增加对V8调试器的支持以及使用Chrome Devtools连接到Deno进程的能力。

我们还看到了构建过程的巨大改进。到目前为止，V8是从Deno的每一个版本的源代码构建的。 V8是一个庞大的C ++项目，可以轻松地花费30多分钟来构建。尽管有大量的构建缓存和其他技巧，但我们一直难以克服。我们增加了rusty_v8在Github发行版上生成和下载预构建静态库的功能，从而允许Deno构建完全绕过V8构建。这简化并加快了CI的构建，但最重要的是，允许贡献者更轻松地构建Deno。

本月用于审查Deno global中的API，以准备发布1.0版。这导致了许多重大变化。我们很保守，所以我们不确定的所有API都被移到--unstable标志之后。

这是1.0版本的主要承诺；标记为“稳定”的Deno API直到2.0发行版才会有重大更改。

删除的原因是由于以下原因我们不想承诺以当前形式支持API：在JSON / WASM导入的情况下缺少底层规范；或使用Rust API装箱的情况下的额外维护负担。

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

但是在我们回到运行时的另一个主要组件上之前，尘埃落定几乎没有：使用SWC重写TypeScript主机中的依赖关系分析。此更改标志着开始努力在Rust中重写TypeScript基础结构的某些部分。

1.0发行版之后，从社区收到的主要抱怨之一是TypeScript的编译和类型检查非常慢。在那里，我们着眼于改进TSC集成以支持增量类型检查。经过几次反复试验的PR，我们能够使功能正常工作，并显着缩短了开发周期。即使我们通过利用TSC的增量API设法提高了类型检查的速度，我们仍然依靠它来发出转译的源。 TypeScript的伟大设计原则之一是它只是具有附加语法的JavaScript，因此剥离类型信息（转换为JavaScript）是一个相对容易的操作。因此，我们设定了能够在Rust中使用SWC进行翻译的目标，同时继续使用TSC进行类型检查。

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

本月，我们做出了一个艰难的决定，将内部运行时代码从TypeScript转换为JavaScript。导致这一决定的因素有很多：在对Deno内部运行时代码的每个版本进行复杂且缓慢的构建过程之前，先对其进行类型检查和捆绑，然后再进行快照。我们有TypeScript编译器主机的两个单独的实现。一个仅用于构建步骤，称为deno_typescript板条箱。另一个包含在非二进制中。另外，整个过程对构建时间有重大影响：2分钟增量重建！通过使用普通的旧JavaScript，我们可以极大地简化内部构建依赖关系和整体复杂性。由于实际的JavaScript代码是由TypeScript编译器作为单个文件束生成的，因此我们几乎无法控制输出代码的外观。 ES模块进行了转换，以在捆绑软件中使用SystemJS加载程序，从而在最终捆绑软件中添加了大量代码。

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

由于正在使用Deno基础结构进行一些非公开工作，因此我们开始努力将Deno系统分解为较小的＆lt; op条板箱＆quot;＆＃34;可以对其进行混合和匹配以生成自定义的V8运行时。八月份，迈出了第一步，发布了deno_web板条箱，提供了一些基本的Web API，例如Event，TextEncoder，TextDecoder。

本月，基准系统用Rust重写。这标志着为减少Denoproject的构建依赖项数量而开始的繁琐工作。

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

该项目的维护部分还有另一个重要变化。发行时间表已更改，从每月的次要发行版更改为每六周发布一次新的次要发行版，以匹配Rust和Chrome项目。

本月发生的最大变化是默认情况下在TypeScript编译器主机中启用了isolatedModules选项。此设置更改TypeScript的行为，以确保可以通过除SWC和Babel之类的TSC之外的其他工具来对每个文件进行隔离转换（不了解类型和/或其他模块）。这一更改对模块生态系统产生了重大影响，使得一些流行的模块无法使用，直到维护人员调整代码以与isolatedModules一起使用。

本月，我们还在SWC中采用了新的捆绑软件功能，这是在原始TypeScript编译器之上使用Rust的又一步。

这个月，我们看到了Kitson Kelly长达数周的重写编译管道项目的结论。它甚至进一步提高了TypeScript转换的速度，但最重要的是还清了许多技术债务。

12月，我们发布了包含两个里程碑功能的1.6版：独立的二进制文件和语言服务器。 deno编译是Deno Bug跟踪器中最需要的一项功能。

提供内置的语言服务器可以为所有可以使用LSP协议的编辑者提供丰富的开发经验。这导致vscode_code的第三次改版仍在进行中。

2020年，我们在项目和社区中看到了巨大的增长。进入2021年，我们对Deno背后的势头充满信心。请继续关注即将推出的一些激动人心的公告！

如果您有兴趣为Deno做贡献，或者只是想了解我们的进度，请查看以下内容：