本文档涵盖了 Deno 项目的 Rust 工作空间配置、依赖管理和构建系统设置。它解释了项目如何使用 Cargo 工作空间进行组织，如何在多个 crate 之间管理依赖项，以及用于开发和发布构建的构建配置。
有关构建这些 Cargo 配置的 CI/CD 管道的信息，请参阅 CI 工作流。
Deno 使用 Cargo 工作空间来管理其多 crate 架构。工作空间配置为解析器版本 2，并将代码库组织成几个逻辑分组。
该工作空间定义了 47 个成员 crate，它们提供了 Deno 功能的不同方面。主要类别包括核心功能、Web 标准扩展、Node.js 兼容性和测试基础设施。
通用包元数据集中在工作空间级别，以确保所有 crate 的一致性。各个 crate 使用 workspace = true 语法继承这些设置。
Deno 使用 [workspace.dependencies] 集中管理依赖项，以确保所有 crate 的版本一致性。这包括内部 Deno crate 和外部依赖项。
| 依赖类别 | 示例 Crates | 版本策略 |
|---|---|---|
| 核心 Deno Crates | deno_core、deno_ast | 带有 = 的精确版本 |
| 外部工具 | tokio、serde、hyper | 兼容版本 |
| 加密库 | ring、rustls、aes | 由工作空间管理 |
| Web 标准 | http、url、mime | 最新兼容 |
依赖项规范对关键组件使用了精确版本锁定
每个扩展都遵循一个通用模式，即依赖工作空间中的 deno_core 和 deno_error，以及特定于域的外部依赖项。
来源：ext/http/Cargo.toml25-58 ext/crypto/Cargo.toml16-49
构建系统使用多个配置来针对不同的用例进行优化
opt-level = 'z'）lto = "thin" 和 codegen-units = 128 加快编译速度关键性能包，如 v8、tokio 和 deno_core，即使在调试构建中也被强制设置为 opt-level = 3。
某些特定包在调试构建中也需要优化
| 包 | 原因 | 优化 |
|---|---|---|
v8 | V8 在 -O0 时会错误编译 | opt-level = 1 |
num-bigint-dig | 加密密钥生成过慢 | opt-level = 3 |
CLI Crates 定义了主 deno 二进制文件，并包含集成测试和带有自定义 harness 的基准测试。
| 功能 | 目的 | 依赖项 |
|---|---|---|
upgrade | 启用升级子命令 | 默认启用 |
dhat-heap | Linux 上的堆分析 | 可选 dhat |
hmr | 热模块重载 | deno_runtime/hmr |
__vendored_zlib_ng | 供应商 zlib-ng | flate2/zlib-ng-compat |
lsp-tracing | LSP 遥测 | tracing-* Crates |
运行时 Crates 使用复杂的特性系统来控制 JavaScript 源的包含和转译功能。
扩展遵循一致的依赖模式
来源：ext/http/Cargo.toml25-58 ext/crypto/Cargo.toml16-49 ext/net/Cargo.toml16-36 ext/node/Cargo.toml19-106
几个扩展包含特定于平台的依赖项
| 平台 | 扩展 | 依赖项 |
|---|---|---|
| Unix | deno_node | errno = "0.3.10" |
| Windows | deno_node | windows-sys、winapi |
| Linux/macOS | deno_net | tokio-vsock |
来源：ext/node/Cargo.toml101-106 ext/net/Cargo.toml35-36
Cargo.lock 文件固定了所有传递性依赖项的精确版本，以确保可重复构建。它拥有超过 1200 个依赖项条目，为整个工作空间提供了完整的依赖解析。
主要特性