<-其他新闻GitHub今天我们发布了Deno 1.8.0。此版本包含大量的新功能和稳定功能:
对WebGPU API的实验支持:在Deno中为开箱即用的GPU加速机器学习铺平道路
支持获取私有模块:使用身份验证令牌从私有服务器获取远程模块
如果您已经安装了Deno,则可以通过运行deno upgrade升级到1.8。如果是首次安装Deno,则可以使用下面列出的方法之一:
WebGPU API为开发人员提供了一种低级,高性能,跨体系结构的方式,可以通过JavaScript编程GPU硬件。它是Web上WebGL的有效前身。规范尚未最终确定,但目前正在Firefox,Chromium和Safari中添加支持。现在也在迪诺。
该API可让您直接从Deno内部访问GPU渲染和通用GPU计算。完成,稳定和取消标记后,这将提供一种从Web,服务器和开发人员机器访问GPU资源的便捷方式。
GPU使程序员可以使某些数值算法高度并行。除了渲染图形和游戏之外,这很有用。在MachineLearning中有效使用GPU已启用了更复杂的神经网络-所谓的DeepLearning。计算机视觉,翻译,图像生成,强化学习等方面的飞速发展都源于有效利用GPU硬件。
如今,大多数神经网络都是使用Python定义的,其计算任务已转移至GPU。我们相信,如果存在适当的基础架构,JavaScript(而不是Python)可以充当表达数学思想的理想语言。在Deno中提供现成的WebGPU支持是朝着这个方向迈出的一步。我们的目标是通过GPU加速在Tensorflow上运行Tensorflow.js。我们预计这将在未来几周或几个月内实现。
这是一个基本示例,演示了如何访问连接的GPU设备以及读取名称和支持的功能:
这是一个小示例,演示了GPU使用渲染着色器在绿色背景上渲染一个简单的红色三角形:
最终的PR占用了多达15.5万行代码,并且在打开后花了整整5个月的时间合并。非常感谢crowlKats领导了将WebGPU集成到Deno中。我们还要感谢为Deno中的WebGPU实现奠定基础的wgpu和gfx-rs项目的所有贡献者。特别感谢WebGPU规范的编辑kvark以及wgpu和gfx-rs的主要开发人员,他们为实现WebGPU API提供了出色的指导。
在Deno存储库中,ICU支持已成为需求第二大的功能。我们很高兴地宣布Deno v1.8附带了完整的ICU支持。
此版本扩展了我们的覆盖范围基础架构,以添加一些强大的新功能。此版本的主要变化是,覆盖率处理现在分为覆盖率集合和覆盖率报告。
以前,覆盖范围的收集和报告都将在单个子命令中进行,方法是在启动deno测试时指定--coverage标志。现在,用于deno测试的--coverage标志带有一个参数-用来存储收集的配置文件的目录的路径。这是coverage集合。在第二步中,您现在调用deno Coverage以及存储coverage配置文件的目录路径。此子命令可以在控制台上直接以漂亮的文本输出形式返回报告,也可以输出lcov文件(--lcovflag)以供genhtml,coveralls.io或codecov.io之类的工具使用。
几天来,我们一直在deno_std上对该功能进行测试。我们将每次提交的覆盖率报告上载到codecov.io。您可以在这里https://codecov.io/gh/denoland/deno_std查看这些内容。添加起来很简单,对我们的GitHub Actions工作流仅进行了10行更改:
导入地图在Chrome 89中已稳定,随后我们的实现已更新为与规范的最新版本相匹配,现在也被认为是稳定的。这意味着使用--import-map时不再需要--unstable标志。
另外,--import-map标志现在不仅接受本地路径,而且接受URL,从而使您可以从远程服务器加载导入地图。
导入映射使用户可以使用所谓的“裸机”。依赖性的说明符,而不是相对或绝对文件/ http URL:
用户应记住,导入映射不可组合:这意味着您只能为deno run / deno测试提供单个导入映射。因此,作者仍应使用常规的,非裸露的说明符(相对或绝对文件/ http URL);否则,该库的用户将需要手动将您的库(和您的库依赖项)裸露的说明符添加到其导入映射中。
导入映射的一个更有用的功能是能够将正则说明符重新映射为完全不同的规范符。例如,如果您的模块图中深深地嵌套了一些brokendependency,则可以在上游修复固定版本之前将其替换为固定版本,或者如果您使用将哈希添加到模块文件名的构建过程,则可以引用该文件源代码中没有哈希值,并且仅在运行时使用importmap重新映射说明符。
并非所有代码都可以在公共互联网上公开获得。以前,Deno无法从需要身份验证的服务器上下载代码。在此版本中,我们增加了用户指定每次首次获取模块时使用的每个域身份验证令牌的功能。
为此,Deno CLI将查找名为DENO_AUTH_TOKENS的环境变量,以确定在请求远程模块时应考虑使用的身份验证令牌。环境变量的值的格式为以分号(;)分隔的n个令牌的格式,其中每个令牌的格式为{token} @ {hostname [:port]}。
当Deno提取与主机名匹配的远程模块的远程模块时,Deno会将请求的Authorization标头设置为Bearer {token}的值。这允许远程服务器识别该请求是绑定到特定经过身份验证的用户的授权请求,并提供对服务器上适当资源和模块的访问。
有关更详细的使用指南和配置您的环境以从私有GitHub存储库中提取信息的说明,请参阅相关的手册条目。
Deno.test API已经具有两个清除程序,可帮助确保您的代码不会“泄漏”。操作或资源-即在测试用例结束之前,已关闭allopen文件/网络句柄,并且没有其他挂起的syscall。
Deno 1.8添加了一个新的清理程序,以确保已测试的代码不会调用Deno.exit()。流氓出口声明可能表示错误的阳性测试结果,并且经常被滥用或忘记删除。
默认情况下,所有测试都会启用此清理程序,但可以通过在测试定义中将sanitizeExit布尔值设置为false来禁用此清理程序。
Deno的安全模型基于权限。当前,只有在启动应用程序时才能授予这些权限。在大多数情况下,此方法效果很好,但在某些情况下,在运行时请求/撤消权限会带来更好的用户体验。
在Deno 1.8中,现在有一个稳定的API可以查询,请求和撤消权限。这些API包含在Deno.permissions对象中。这是一个如何工作的示例:
//尝试获取主目录(此操作将失败,因为还没有env权限)。
在稳定之前,这些API都要经过安全审查,并且必须获得适当的权限才能使用它们。
随着Deno变得更加稳定,对于开发人员来说,使用简便的方法来检测其应用程序变得越来越重要。这从最低级别开始,即在运行时本身。在Deno中,JS中的所有特权操作(转到Rust的操作)都是通过JS和Rust之间的单个中央接口来完成的。我们称通过该接口的问题为“&op34”。例如,调用Deno.open将调用op_open_async op到特权端,这将返回打开文件的源ID(或错误)。
两年多以前,即2018年10月11日,我们为您提供了一种查看Rust和JS之间所有操作的指标的方法:Deno.metrics。该API当前公开了已开始和已完成的同步和异步操作的计数,以及通过操作接口发送的数据量。到目前为止,这仅限于所有不同操作的组合数据。没有办法确定哪个操作被调用了多少次,只有一般的所有操作。
与--unstable一起运行时,此版本向Deno.metrics添加了一个名为ops的新字段。此字段包含每个操作的信息,这些信息涉及API的调用频率以及已通过API传输了多少数据。这允许对运行时进行更多粒度的检测。
在即将发布的版本中,Deno.test中的异步opsanitizer将使用此新信息,以在测试完成之前未完成异步操作时提供更多可操作的错误。我们已经看到此功能用于检测应用程序并将数据通过管道传输到监视软件中:
deno fmt现在可以格式化.json和.jsonc文件。就像JS / TS一样,formatter还将在markdown文件中格式化json和jsonc代码块。
默认情况下,输出格式仍为esm,但用户可以通过将EmitOptions.bundle选项设置为iife来更改此格式:
在过去的几个月中,我们一直在努力替代VSCode(Deno扩展)的旧编辑器集成。旧的扩展名仅适用于VS Code,而且解析的类型并不总是与DenoCLI中的类型匹配。
在Deno 1.6中,我们在canary(Deno的内置语言服务器)中发布了deno lsp。 LSP使我们能够从单个代码库向所有支持LSP的编辑器提供编辑器集成。内置的语言服务器与Deno CLI的其余部分基于相同的体系结构-因此,它提供的TypeScript诊断功能与CLI的其余部分相同。
两周前,在Deno 1.7.5中,我们稳定了deno lsp并切换了正式的VS Code扩展以使用它。到目前为止,我们已经收到了很好的反馈,并将努力解决所有报告的问题。如果您在扩展程序中遇到问题,请在我们的问题跟踪器中报告。我们无法解决我们不知道的问题。
除了官方的VS Code集成以外,还创建了更多基于deno lsp构建的社区集成: