<-其他新闻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子命令,它在幕后只是" deno run"的别名。指向更漂亮。这意味着在首次运行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系统分解为较小的< op条板箱""可以对其进行混合和匹配以生成自定义的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做贡献,或者只是想了解我们的进度,请查看以下内容: