Deno 2.0 发布候选版

更新 2024/10/04: 我们已发布 Deno 2.0 发布候选版本的多项更新。

多年来，我们一直在计划 Deno 的新主要版本。很多次，它似乎即将发布，但我们意识到我们想要的功能需要更多工作。现在，它终于要来了。上个月，我们发布了最终的 1.x 版本 1.46，今天，我们正在发布 Deno 2.0 的候选版本，其中包含了我们期望最终版本中的所有内容。这是自 1.0 以来最大的更新，带来了像引入 Node 的 process 全局变量这样的重大变化。我们还做了一些理念上的转变，例如更倾向于使用 deno install 而不是现在已弃用的 deno cache。请继续阅读以了解完整的变更列表，并分享您的反馈！

要试用发布候选版本，请在您的终端中运行以下指令

deno upgrade
deno upgrade rc

ℹ️ 如果您使用 Homebrew 等其他分发方式，deno upgrade 可能不可用。

请遵循 https://deno.org.cn 上的安装说明，然后运行上述命令。

Deno 2.0 发布候选版本新特性

• 全局变量 window 和 process 的变更
• 依赖管理
• 权限系统变更
• API 变更
• CLI 变更
• Import 断言已死，Import 属性万岁
• Node.js 和 npm 兼容性
• 使用 deno test --doc 进行文档测试
• TypeScript 变更
• 致谢
• 接下来做什么？

🚨️ 我们正在积极征求反馈 🚨️

此发布候选版本有助于我们在最终 2.0 版本发布之前识别问题。如果您遇到任何问题或需要额外指导，请在 GitHub 上创建议题或在我们 Discord 的 #deno-2-help 频道中提问。我们的团队正在积极监控这两个地方，并将尽快提供帮助。

全局变量变更

Deno 2 对全局变量进行了两项重大更改 — window 已移除，Node 的 process 现已可用。

我们在 Deno v1.0 中引入了 window 全局变量，目标是让 Deno 尽可能与浏览器兼容。不幸的是，window 全局变量成为了用户问题的根源。

许多库通过探测 window 全局变量而不是检查 DOM 的存在来判断它们是否在浏览器中执行。这导致了一些库出现一类错误，这些库原本可以在 Deno 中工作，但由于 window 的全局可用性而出现问题。

Deno 在 v1.40 中开始不鼓励使用 window 全局变量，建议改用 globalThis 或 self。

// Deno v1.x
window.addEventListener("load", () => {
  console.log("loaded");
});

// Deno v2.x
globalThis.addEventListener("load", () => {
  console.log("loaded");
});

相比之下，process 全局变量被广泛请求。

尽管长期以来可以通过从 node:process 模块导入来使用 process，但许多流行的框架依赖于其在全局范围内的存在，并且经常在配置文件中使用。

尽管添加 import process from 'node:process'; 看起来很简单，但对于那些原本可以在 Deno 中无缝运行的流行框架的用户来说，这常常会造成摩擦。

因此，随着 process 全局变量的添加，您可以预期更多最初为 Node.js 编写的代码可以在 Deno 中无需修改即可运行。但是，我们仍然鼓励用户优先使用显式导入。为此，我们添加了一个新的 no-process-global lint 规则，它将在您的编辑器中提供提示和快速修复，以改用 import 语句。

依赖管理

Deno 2 带来多项新功能，改进了依赖管理。

deno add 子命令现在支持带有子路径的说明符

# Before in Deno v1.46
deno add jsr:@std/testing/snapshot
error: Failed to parse package required: @std/testing/snapshot

Caused by:
    0: Invalid package requirement '@std/testing/snapshot'. Invalid version requirement. Invalid specifier version requirement. Unexpected character '/'
    ...

# Deno v2.0
deno add jsr:@std/testing/snapshot
Add jsr:@std/testing@1.0.2

# Deno v1.46
deno add npm:preact/hooks
error: Failed to parse package required: npm:preact/hooks

Caused by:
    0: Invalid package requirement 'preact/hooks'. Packages in the format <scope>/<name> must start with an '@' symbol.
    1: Packages in the format <scope>/<name> must start with an '@' symbol.

# Deno v2.0
deno add npm:preact/hooks
Add npm:preact@10.24.0

ℹ️ 在添加依赖时，现在需要使用 jsr: 或 npm: 前缀，以避免两个注册表中同名包之间可能存在的歧义。

如果您省略前缀，Deno 将打印包含正确调用方式的建议，并检查哪些注册表包含该包。

此外，如果您的项目包含 package.json 文件，Deno 将优先把 npm: 依赖项添加到 package.json 中，而不是 deno.json。

cat package.json
{
  "dependencies": {}
}

deno add npm:express
Add npm:express@5.0.0

cat package.json
{
  "dependencies": { "express": "^5.0.0" }
}

您还可以使用 --dev 标志将“开发依赖项”添加到 package.json 中

deno add --dev npm:express
Add npm:express@5.0.0

cat package.json
{
  "devDependencies": { "express": "^5.0.0" }
}

deno install 现在支持 --entrypoint 标志，允许您从给定的模块中安装所有依赖项

// main.ts
import snapshot from "jsr:@std/testing/snapshot";
import express from "npm:express";

deno install --entrypoint main.ts
Download ...

新增了 deno remove 子命令，可快速移除部分依赖项

deno add jsr:@std/testing
Added jsr:@std/testing@1.0.2

cat deno.json
{
  "imports": { "@std/testing": "jsr:@std/testing@^1.0.2" }
}

deno remove @std/testing
Removed @std/testing

cat deno.json
{}

您也可以使用 deno remove 处理 package.json 中列出的依赖项。

Deno 2 附带了新的、更简洁的锁文件格式 (v4)，它将在更新依赖项时最大程度地减少差异，并确保可重现的构建。

cat deno.lock
{
  "version": "4",
  "specifiers": {
    "jsr:@std/assert@^1.0.4": "1.0.5",
    "jsr:@std/data-structures@^1.0.2": "1.0.4",
    "jsr:@std/fs@^1.0.3": "1.0.3",
    "jsr:@std/internal@^1.0.3": "1.0.3",
    "jsr:@std/path@^1.0.4": "1.0.6",
    "jsr:@std/testing@*": "1.0.2",
    "jsr:@std/testing@^1.0.2": "1.0.2"
  },
  // ...
}

Deno 将自动将您迁移到新的锁文件格式。

最后，Deno 改进了错误消息，为常见问题提供了有用的提示，例如格式不正确的相对导入路径，或使用“裸说明符”时缺少依赖项。

// main.ts
import "@std/dotenv/load";

deno run main.ts
error: Relative import path "@std/dotenv/load" not prefixed with / or ./ or ../
  hint: Try running `deno add jsr:@std/dotenv/load`
    at file:///main.ts:1:8

这些更新共同简化了 Deno 项目中的依赖管理流程，使其更加直观，并与现代开发工作流程保持一致。

权限系统变更

新的 Deno.errors.NotCapable 错误

Deno 的权限系统是其最受欢迎的功能之一。当程序尝试访问未使用 --allow-* 标志允许的 API 时，会引发错误。在 Deno v1.x 中，这是 Deno.errors.PermissionDenied。

然而，这有一个问题。所有操作系统也会引发此错误，例如当您的用户无权访问仅限管理员的文件，或者当您尝试监听特权端口时。因此，用户常常对即使使用 --allow-all 标志运行也会引发此错误感到困惑。

在 Deno v2.0 中，缺少 Deno 权限现在会引发 Deno.errors.NotCapable 错误，以便更容易区分操作系统级别错误和 Deno 错误。

await Deno.readTextFile("./README.md");

Deno v1.46

$ deno run main.ts
error: Uncaught (in promise) PermissionDenied: Requires read access to "./README.md", run again with the --allow-read flag
await Deno.readTextFile("./README.md")
           ^
    at Object.readTextFile (ext:deno_fs/30_fs.js:878:24)
    at file:///main.ts:1:12

Deno v2.0

$ deno run main.ts
error: Uncaught (in promise) NotCapable: Requires read access to "./README.md", run again with the --allow-read flag
await Deno.readTextFile("./README.md")
           ^
    at Object.readTextFile (ext:deno_fs/30_fs.js:777:24)
    at file:///main.ts:1:12

Deno.mainModule 不再需要 --allow-read 权限

Deno.mainModule API 的权限检查已放宽，该 API 提供主模块的完整路径，不再需要完整的 --allow-read 权限。这也适用于 process.argv API。

此要求已弃用，但主模块的路径可以通过创建 Error 实例并检查其堆栈跟踪来获取。

--allow-hrtime 标志已移除

Deno v1.x 有一个 --allow-hrtime 标志，影响了像 performance.now() 这样提供高精度计时的 API。在 Deno 2 中，此标志已移除，这些 API 始终提供高精度计时。

此标志已弃用，因为高精度计时可以使用标准 JavaScript API（如 Worker 和 SharedArrayBuffer）实现。

--allow-run 标志变更

--allow-run 标志有一些重大变更，旨在引导您更安全地执行子进程。

首先，如果您在使用 --allow-run 标志时未指定二进制名称或二进制路径的允许列表，将会出现警告。

new Deno.Command("echo", { args: ["hello"] }).spawn();

$ deno run --allow-run main.ts
Warning --allow-run without an allow list is susceptible to exploits. Prefer specifying an allow list (https://docs.deno.org.cn/runtime/fundamentals/security/#running-subprocesses)
hello

然后，无论何时使用 LD_* 或 DYLD_* 环境变量生成子进程，都将需要完整的 --allow-run 权限。请注意，这些环境变量很少会被依赖。如果您确实需要使用它们，则应考虑通过运行额外的保护层（例如 Docker 容器）来进一步沙盒化 Deno。

new Deno.Command("echo", {
  env: {
    "LD_PRELOAD": "./libpreload.so",
  },
}).spawn();

$ deno run --allow-run=echo main.ts
error: Uncaught (in promise) NotCapable: Requires --allow-all permissions to spawn subprocess with LD_PRELOAD environment variable.
}).spawn();
   ^
    at spawnChildInner (ext:runtime/40_process.js:182:17)
    at spawnChild (ext:runtime/40_process.js:205:10)
    at Command.spawn (ext:runtime/40_process.js:479:12)
    at file:///main.ts:5:4

文件名中的逗号转义

现在可以授予包含逗号的文件名的读写权限。

在 Deno v1.x 中，逗号用于分隔多个文件名

deno run --allow-read=file1.txt,file2.txt
# grants permission to read `file1.txt` and `file2.txt`

这使得无法授予包含逗号的文件名权限。

在 Deno 2 中，可以通过使用另一个逗号转义逗号来实现这一点

deno run --allow-read=file,,.txt,file2.txt
# grants permission to read `file,.txt` and `file2.txt`

API 变更

稳定版 API

Deno 2 中有多个 API 已稳定

• WebGPU API 不再需要 --unstable-webgpu 标志
• Deno.dlopen() 和其他 FFI API 不再需要 --unstable-ffi 标志
• Deno.createHttpClient() 不再需要 --unstable-http 标志

错误消息也得到了改进，当您尝试使用不稳定的 API 而未带相应的标志时，会提供有用的提示。

const db = await Deno.openKv();

Deno v1.46

$ deno run db.ts
error: Uncaught (in promise) TypeError: Deno.openKv is not a function
const db = await Deno.openKv();
                      ^
    at file:///db.ts:1:23

Deno v2.0

error: Uncaught (in promise) TypeError: Deno.openKv is not a function
const db = await Deno.openKv();
                      ^
    at file:///db.ts:1:23

    info: Deno.openKv() is an unstable API.
    hint: Run again with `--unstable-kv` flag to enable this API.

Deno API 的重大变更

ℹ️ 有关如何从已弃用 API 迁移的更多信息，请访问Deno 1 到 2 迁移指南

以下 API 已移除

• Deno.Buffer
• Deno.close()
• Deno.copy()
• Deno.customInspect
• Deno.fdatasync() 和 Deno.fdatasyncSync()
• Deno.File（此外 Deno.FsFile 不能再手动构造）
• Deno.flock() 和 Deno.flockSync()
• Deno.fstat() 和 Deno.fstatSync()
• Deno.fsync() 和 Deno.fsyncSync()
• Deno.ftruncate() 和 Deno.ftruncateSync()
• Deno.funlock() 和 Deno.funlockSync()
• Deno.futime() 和 Deno.futimeSync()
• Deno.iter() 和 Deno.iterSync()
• Deno.metrics()
• Deno.read() 和 Deno.readSync()
• Deno.readAll() 和 Deno.readAllSync()
• Deno.resources()
• Deno.seek() 和 Deno.seekSync()
• Deno.shutdown()
• Deno.write() 和 Deno.writeSync()
• Deno.writeAll() 和 Deno.writeAllSync()

TLS 选项处理已更新，以下选项不再受支持

• Deno.ConnectTlsOptions.certChain
• Deno.ConnectTlsOptions.certFile
• Deno.ConnectTlsOptions.privateKey
• Deno.ListenTlsOptions.certChain
• Deno.ListenTlsOptions.certFile
• Deno.ListenTlsOptions.keyFile

以下接口已移除

• Deno.Closer
• Deno.Reader 和 Deno.ReaderSync
• Deno.Seeker 和 Deno.SeekerSync
• Deno.Writer 和 Deno.WriterSync

此外，一些与 DNS 记录处理相关的接口已重命名

• Deno.CAARecord 更名为 Deno.CaaRecord
• Deno.MXRecord 更名为 Deno.MxRecord
• Deno.NAPTRRecord 更名为 Deno.NaptrRecord
• Deno.SOARecord 更名为 Deno.SoaRecord
• Deno.SRVRecord 更名为 Deno.SrvRecord

以下 API 中不再提供“资源 ID”

• Deno.FsWatcher.prototype.rid
• Deno.Conn.prototype.rid
• Deno.TlsConn.prototype.rid
• Deno.TcpConn.prototype.rid
• Deno.UnixConn.prototype.rid
• Deno.FsFile.prototype.rid
• Deno.Listener.prototype.rid
• Deno.TlsListener.prototype.rid

最后，一些 API 已被“软弃用”。这些 API 将继续工作，但不再接收更新或错误修复。强烈建议并鼓励迁移到稳定的对应 API。

• Deno.serveHttp() - 请改用 Deno.serve()
• Deno.run() - 请改用 new Deno.Command()
• Deno.isatty(Deno.stdin.rid) - 请改用 Deno.stdin.isTerminal()
• Deno.isatty(Deno.stdout.rid) - 请改用 Deno.stdout.isTerminal()
• Deno.isatty(Deno.stderr.rid) - 请改用 Deno.stderr.isTerminal()

命令行界面变更

Deno 2 移除了对两个子命令的支持

• deno bundle - 此子命令在 Deno v1.31 中已弃用，原因是用户期望与内置打包器提供的实际功能不符。

  许多 Deno 用户期望一个通用且高度可定制的打包器。然而，Deno 的内置打包器旨在作为一种简单的工具，将多个文件连接成一个文件以便于分发；并且没有设置可以定制任何行为。

  我们计划实现一个新的内置打包器，敬请关注未来版本的更新。

• deno vendor - 在 Deno v1.45 中已弃用，并被更简单的解决方案取代，即使用Deno v1.37 中引入的 deno.json 文件中的 vendor 选项。

几个 CLI 标志现已弃用

• --lock-write - 请改用 --frozen
• --unstable - 请改用更细粒度的 --unstable- 标志
• test --allow-none - 请改用 test --permit-no-files
• --jobs - 请改用 DENO_JOBS 环境变量
• test --trace-ops - 请改用 test --trace-leaks
• --ts - 请改用 --ext=ts

此外，您可以使用 DENO_LOG 环境变量来启用调试日志，而不是 RUST_LOG。

最后，配置文件中的 files 选项现已弃用。

在 Deno v1.x 中，支持此语法

{
  "test": {
    "files": {
      "include": ["**/*.ts"],
      "exclude": ["ignore.ts"]
    }
  }
}

在 Deno 2 中，files 配置已简化，并已扁平化到父配置中。

{
  "test": {
    "include": ["**/*.ts"],
    "exclude": ["ignore.ts"]
  }
}

Import 断言已死，Import 属性万岁

Import 断言支持在 Deno v1.46 中已弃用，在 Deno 2 中不再可用。

原因是该提案经历了重大变更，包括将关键字从 assert 更新为 with，并更名为Import Attributes，此外一些浏览器（例如 Chrome）也已经取消了对 Import Assertions 的支持。

以下是更新后的样子

- import data from "./data.json" assert { type: "json" };
+ import data from "./data.json" with { type: "json" };

Node.js 和 npm 兼容性

改进的 CommonJS 支持

自 1.0 版本发布以来，Deno 一直将 ES 模块作为主要模块系统，仅通过手动创建 require 提供有限的 CommonJS 支持。

import { createRequire } from "node:module";
const require = createRequire(import.meta.url);
require("...");

尽管我们坚信ES 模块是 JavaScript 的未来，但 2024 年的现状仍然包含大量依赖 CommonJS 的库和项目。

尽管 Deno 在过去一年中对 CJS 库进行了强大的处理，但用户在集成 CommonJS 时偶尔会遇到挑战，尤其是在他们自己的代码库中。

在 Deno 2 中，进行了一些改进，以帮助使用 CommonJS 模块并简化向 ES 模块的过渡

• deno run index.cjs - Deno 现在可以执行 CommonJS 文件，前提是它们使用 .cjs 扩展名。Deno 不会查找 package.json 文件和 type 选项来确定文件是 CommonJS 还是 ESM。

  使用此选项时，Deno 也不会自动安装依赖项，因此您需要预先手动运行 deno install 以确保所有必需的依赖项都可用。

// index.cjs
const express = require("express");

注意：Deno 权限系统仍然有效，因此 require() 调用会提示需要 --allow-read 权限。

deno run index.cjs
┏ ⚠️  Deno requests read access to "/dev/example".
┠─ Learn more at: https://docs.deno.org.cn/go/--allow-read
┠─ Run again with --allow-read to bypass this prompt.
┗ Allow? [y/n/A] (y = yes, allow; n = no, deny; A = allow all read permissions) >

• import cjs from "./index.cjs" - Deno 现在可以导入 CommonJS 文件，前提是它们使用 .cjs 扩展名。Deno 不会查找 package.json 文件和 type 选项来确定文件是 CommonJS 还是 ESM。

// greet.cjs
module.exports = {
  hello: "world",
};

import greet from "./greet.cjs";
console.log(greet);

deno run main.js
{
  "hello": "world"
}

• require(ESM) - Deno 现在支持 require ES 模块。这只有在所需的模块不使用 Top-Level Await 的情况下才可能实现。此更改应在使用依赖 CommonJS 和 ESM 的混合依赖项时改善互操作性。

// greet.js
export function greet(name) {
  return `Hello ${name}`;
}

// esm.js
import { greet } from "./foo.js";

export { greet };

// main.cjs
const esm = require("./esm");
console.log(esm);
console.log(esm.greet("Deno"));

deno run --allow-read main.cjs
[Module: null prototype] { greet: [Function: greet] }
Hello Deno

• 处理 CommonJS 模块时提供更好的错误建议，指导您编写可运行的程序。

// main.js
module.exports = {
  foo: "foo",
};

deno run main.js
error: Uncaught (in promise) ReferenceError: module is not defined
module.exports = {
^
    at file:///Users/ib/dev/deno/main.js:1:1

    info: Deno does not support CommonJS modules without `.cjs` extension.
    hint: Rewrite this module to ESM or change the file extension to `.cjs`.

自带 node_modules 是默认设置

“自带 node 模块”功能在 Deno v1.38 中引入。

ℹ️ 尽管我们仍然强烈主张不依赖本地 node_modules 目录，但许多现有项目和框架都是基于该目录将存在的假设来运行的。

但有时即使您没有 package.json，您仍然希望拥有一个本地的 node_modules 目录 — 例如，在使用 Next.js、Remix 或 Svelte 等框架时；或者依赖使用 Node-API 的 npm 包，如 duckdb、sqlite3、esbuild 等。为提高兼容性，如果项目包含 package.json 文件，Deno 将期望 node_modules 目录是手动设置的。

在之前的 Deno 版本中，您可以使用 --node-modules-dir 标志或配置文件中的 nodeModulesDir 选项来告诉 Deno 是否应该创建 node_modules 目录。

Deno 2 更改了此配置选项 — 它不再是布尔值，而是具有三个选项的枚举

默认模式

deno run main.ts

# or

deno run --node-modules-dir=none main.ts

或通过配置文件

{
  "nodeModulesDir": "none"
}

这是 Deno 优先项目的默认模式 — 即不包含 package.json 文件的项目。它会自动将依赖项安装到全局缓存中，并且不会创建本地 node_modules 目录。

ℹ️ 推荐用于新项目。请注意，期望 node_modules 目录的框架将无法工作，此外任何依赖 postinstall 脚本的 npm 依赖项也将无法工作。

auto 模式

deno run --node-modules-dir=auto main.ts

或通过配置文件

{
  "nodeModulesDir": "auto"
}

auto 模式会自动将依赖项安装到全局缓存中，并在项目根目录创建本地 node_modules 目录。

ℹ️ 推荐用于具有依赖 node_modules 目录的 npm 依赖项的项目 — 主要使用打包器或具有 postinstall 脚本的 npm 依赖项的项目。

manual 模式

deno run --node-modules-dir=manual main.ts

或通过配置文件

{
  "nodeModulesDir": "manual"
}

manual 模式是使用 package.json 项目的默认模式。此模式是 Node.js 使用的工作流，需要使用 deno install/npm install/pnpm install 或任何其他包管理器进行显式安装步骤。

ℹ️ 推荐用于使用 Next.js、Remix、Svelte、Qwik 等框架；或 Vite、Parcel、Rollup 等工具的项目。

建议使用默认的 none 模式，如果遇到抱怨 node_modules 目录中缺少包的错误，则回退到 auto 或 manual 模式。

Node.js API 兼容性

在支持内置 Node.js API 方面再次取得了巨大进展，使得更多流行包获得支持

• node:crypto 收到了大量更新
  • 支持 MD4 摘要，修复 npm:docusaurus
  • Cipheriv.update(string, undefined) 现在可以正常工作
  • 当禁用 autoPadding 选项时，Decipheriv 也能正常工作
  • 现在支持导出 JWK 公钥…
  • 以及导入 EC JWK 密钥…
  • 以及导入 JWK 八位字节对密钥…
  • 以及导入 RSA JWK 密钥…
  • 最后，支持 npm:web-push
• async_hooks.AsyncLocalStorage 现在性能更佳，更可靠
• 现在支持 npm:detect-port 和 npm:portfinder
• npm:ssh2 获得更好的支持
• 以及npm:elastic-apm-node也获得更好的支持
• node:wasi 现在已存根
• node:events 和 node:util 现在覆盖率更高
• npm:puppeteer 由于添加了 FileHandle#writeFile API 和更好的 socket 升级处理而更可靠
• node:constants、node:fs、node:path node:vm 和 node:zlib 导出了缺失的常量
• node:trace_events 现在已存根且不会崩溃
• node:timers 现在导出了 promises 符号
• npm:qwik 和 npm:hono 由于http2 模块的修复而更可靠
• npm:playwright 由于child_process 中对 detached 选项的支持而更稳定
• v8 模块获得了对 Serializer 和 Deserializer API 的更好支持，使 npm:parcel 能够正常工作
• 以及更多…

使用 deno test --doc 进行文档测试

JSDoc 是一种用于为 JavaScript 和 TypeScript 编写内联文档的格式。它是 deno doc 和 JSR 自动生成其模块文档的方式。

JSDoc 允许我们直接在注释中编写代码示例

/**
 * ```ts
 * import { assertEquals } from "jsr:@std/assert/equals";
 *
 * assertEquals(add(1, 2), 3);
 * ```
 */
export function add(a: number, b: number) {
  return a + b;
}

然而有一个问题……你如何确保这些示例保持最新并且不会“代码腐烂”？

Deno v1.10 添加了类型检查示例的功能，这有助于解决问题，但并未完全解决。确保示例最新的唯一方法是实际执行它们。

在 Deno 2 中，deno test --doc 不仅对 JSDoc 中的示例进行类型检查，还会执行它们。

要测试您的 JSDoc 示例，只需运行 deno test --doc，Deno 将自动发现并运行相关的代码块。

ℹ️ 如果您只想类型检查您的示例，仍然可以通过运行 deno check --doc 来实现。

但这还不是全部！除了测试 JSDoc 示例，您还可以在 Markdown 文件中执行代码块

这是此功能的首次迭代，我们感谢您的任何反馈。

TypeScript 变更

Deno v2.0 附带 TypeScript 5.6，您可以在 宣布 TypeScript 5.6 博客文章中阅读更多内容。

为帮助捕获常见陷阱，以下 TypeScript 设置现在默认启用

• useUnknownInCatchVariables
• noImplicitOverride

此外，Deno 2 内置支持 @types/node 版本 22，以便更轻松地对依赖 Node.js API 的代码进行类型检查。

最后，为确保您的 compilerOptions 设置是最新的，我们已将其列为允许列表，因此如果您使用不受支持的选项，Deno 将会报错并标记。

致谢

没有社区的帮助，我们无法构建 Deno！无论是通过在我们的社区 Discord 服务器中回答问题，还是报告错误，我们都非常感谢您的支持。在此，我们要特别感谢以下人员对 Deno 2 发布候选版本的贡献：Andreas Deininger, Armaan Salam, Bedis Nbiba, Birk Skyum, Bob Callaway, Caleb Cox, Caleb Lloyd, Coty, Hajime-san, HasanAlrimawi, Ian Bull, Ivancing, Jake Abed, Kamil Ogórek, Kenta Moriuchi, Kyle Kelley, Mohammad Sulaiman, MrEconomical, MujahedSafaa, Pig Fang, Rano | Ranadeep, Roy Ivy III, Sean McArthur, Sʜɪᴍᴜʀᴀ Yū, Victor Turansky, Yazan AbdAl-Rahman, Zebreus, chirsz, cions, i-api, melbourne2991, seb, vwh, 和 Łukasz Czerniawski。

您想加入 Deno 贡献者的行列吗？请在此处查看我们的贡献文档，下次我们会在列表中看到您。

感谢您关注 Deno 2 发布候选版本，我们希望您喜欢使用 Deno 进行开发！

下一步是什么？

此发布候选版本正朝着我们的 2.0 版本发布努力，预计会有错误和问题。如果您遇到任何问题，请通过 GitHub 议题（带有 2.0 标签）或在我们 Discord 的专用 #deno-2-help 频道告知我们。我们正在积极监控这两个区域，以确保在 2.0 版本发布之前修复所有主要错误。