# System map — denoland/deno

> Canonical page: https://codevetter.com/unpack/deno/system-map

# System map — denoland/deno

Scanned commit 461f32ec6174d88b7e43654a054d46d67ae2fdab (2026-09-21). Generated by codevetter codevetter 1.12.0 on 2026-09-22.

The binary entry is a nine-line `cli/main.rs` that delegates to `deno::main()` in `cli/lib.rs`, which parses flags, initialises V8, and dispatches a `DenoSubcommand` to a handler under `cli/tools/`. Shared services are constructed lazily through `CliFactory`, a container of `Deferred<T>` once-cells covering caches, resolvers, the file fetcher, npm installer, type checker, and permission container. The JS runtime is assembled in `runtime/worker.rs::common_extensions`, which registers ~35 extension crates from `ext/` in a strict, snapshot-sensitive order; a V8 startup snapshot is baked at build time by `cli/snapshot/build.rs`. Storage is the DENO_DIR: SQLite caches (`cli/cache/caches.rs`) for dep analysis, type checking, code cache, fast-check, and lint/fmt incremental state, plus an HTTP cache and npm package cache. Builds run through `cargo`/`./x`, CI is generated TypeScript (`.github/workflows/ci.ts` → `ci.generated.yml`), and the deployment shape is a single statically-linked executable distributed per-platform.
- `cli/main.rs` is deliberately a 9-line shim calling `deno::main()`; the real entrypoint is `pub fn main()` in `cli/lib.rs`, which sets a panic hook, raises the fd limit, installs the aws-lc-rs rustls crypto provider, and runs everything inside `create_and_run_current_thread_with_maybe_metrics`. — [cli/main.rs#L1-9](https://github.com/denoland/deno/blob/461f32ec6174d88b7e43654a054d46d67ae2fdab/cli/main.rs#L1-L9) [cli/lib.rs#L863-960](https://github.com/denoland/deno/blob/461f32ec6174d88b7e43654a054d46d67ae2fdab/cli/lib.rs#L863-L960)
- Subcommand dispatch is a single `match flags.subcommand` in `run_subcommand` (cli/lib.rs:124-556) mapping each `DenoSubcommand` variant to a `tools::*` handler wrapped in `spawn_subcommand`, which boxes the future locally specifically to avoid blowing the stack on Windows debug builds. — [cli/lib.rs#L112-556](https://github.com/denoland/deno/blob/461f32ec6174d88b7e43654a054d46d67ae2fdab/cli/lib.rs#L112-L556)
- `DenoSubcommand` is defined in the vendored parser crate at `libs/cli_parser/src/flags.rs:786` with 47 variants (Add, Audit, Bundle, Compile, Deploy, Desktop, Jupyter, Lsp, Pack, Publish, X, …); the CLI re-exports it via `pub use deno_cli_parser::flags::*` in `cli/args/flags.rs`. — [libs/cli_parser/src/flags.rs#L786-833](https://github.com/denoland/deno/blob/461f32ec6174d88b7e43654a054d46d67ae2fdab/libs/cli_parser/src/flags.rs#L786-L833) [cli/args/flags.rs#L12-14](https://github.com/denoland/deno/blob/461f32ec6174d88b7e43654a054d46d67ae2fdab/cli/args/flags.rs#L12-L14)
- Flag parsing is a hand-written zero-cost parser, not clap: `libs/cli_parser/src/defs.rs` declares the whole command tree as `const` `ArgDef`/`CommandDef` tables living in `.rodata`, `parse.rs` walks argv against them, and `convert.rs` turns the `ParseResult` into `Flags`; `help.rs` and `completions.rs` render from the same tables. — [libs/cli_parser/src/lib.rs#L1-25](https://github.com/denoland/deno/blob/461f32ec6174d88b7e43654a054d46d67ae2fdab/libs/cli_parser/src/lib.rs#L1-L25) [libs/cli_parser/src/defs.rs#L1-30](https://github.com/denoland/deno/blob/461f32ec6174d88b7e43654a054d46d67ae2fdab/libs/cli_parser/src/defs.rs#L1-L30)
- `CliFactory` is the dependency-injection root: `CliFactoryServices` holds ~25 `Deferred<T>` (once-cell) slots — `caches`, `file_fetcher`, `npm_installer_factory`, `resolver_factory`, `type_checker`, `root_permissions_container`, `module_graph_builder` — so a subcommand only constructs the services it actually touches. — [cli/factory.rs#L255-345](https://github.com/denoland/deno/blob/461f32ec6174d88b7e43654a054d46d67ae2fdab/cli/factory.rs#L255-L345) [cli/factory.rs#L383-440](https://github.com/denoland/deno/blob/461f32ec6174d88b7e43654a054d46d67ae2fdab/cli/factory.rs#L383-L440)
- The JS runtime's extension set is one ordered `vec![]` in `runtime/worker.rs::common_extensions` (line 1199) listing deno_telemetry, deno_webidl, deno_web, deno_webgpu, deno_image, deno_canvas, deno_fetch, deno_cache, deno_websocket, deno_webstorage, deno_crypto, deno_ffi, deno_net, deno_tls, deno_kv, deno_cron, deno_napi, deno_http, deno_io, deno_fs, deno_os, deno_process, deno_node_crypto, deno_node_sqlite, deno_node, plus crate-local ops; a comment warns ordering must stay in sync with `web_worker.rs`, `snapshot_info.rs`, and `snapshot.rs`. — [runtime/worker.rs#L1199-1262](https://github.com/denoland/deno/blob/461f32ec6174d88b7e43654a054d46d67ae2fdab/runtime/worker.rs#L1199-L1262)
- `deno_core` is vendored into this repo as `libs/core` (package name `deno_core`, version 0.412.0) rather than consumed from crates.io, alongside `libs/serde_v8`, `libs/ops` (the `#[op2]` proc macro), and `libs/deno_v8`; `libs/dcore/src/main.rs` is a standalone dev harness binary for that core. — [libs/core/Cargo.toml#L1-14](https://github.com/denoland/deno/blob/461f32ec6174d88b7e43654a054d46d67ae2fdab/libs/core/Cargo.toml#L1-L14) [libs/ops/lib.rs#L25-27](https://github.com/denoland/deno/blob/461f32ec6174d88b7e43654a054d46d67ae2fdab/libs/ops/lib.rs#L25-L27) [libs/dcore/src/main.rs#L1-30](https://github.com/denoland/deno/blob/461f32ec6174d88b7e43654a054d46d67ae2fdab/libs/dcore/src/main.rs#L1-L30) [Cargo.toml#L38-60](https://github.com/denoland/deno/blob/461f32ec6174d88b7e43654a054d46d67ae2fdab/Cargo.toml#L38-L60)
- Persistent state lives in DENO_DIR as SQLite `CacheDB`s created by `cli/cache/caches.rs`: `fmt_incremental_cache_db`, `lint_incremental_cache_db`, `dep_analysis_db`, `fast_check_db`, `node_analysis_db`, `type_checking_cache_db`, and `code_cache_db`; `CliFactory::caches()` pre-warms the relevant ones based on the subcommand. — [cli/cache/caches.rs#L19-140](https://github.com/denoland/deno/blob/461f32ec6174d88b7e43654a054d46d67ae2fdab/cli/cache/caches.rs#L19-L140) [cli/cache/mod.rs#L1-30](https://github.com/denoland/deno/blob/461f32ec6174d88b7e43654a054d46d67ae2fdab/cli/cache/mod.rs#L1-L30) [cli/factory.rs#L405-430](https://github.com/denoland/deno/blob/461f32ec6174d88b7e43654a054d46d67ae2fdab/cli/factory.rs#L405-L430)
- A V8 startup snapshot is produced at build time: `cli/snapshot/build.rs` calls `deno_runtime::snapshot::create_runtime_snapshot` writing `CLI_SNAPSHOT.bin` plus `EXTENSION_RESIDUAL_SOURCES.rs`, and `cli/build.rs` compresses ~60 TypeScript `lib.*.d.ts` declaration files into the binary. — [cli/snapshot/build.rs#L1-40](https://github.com/denoland/deno/blob/461f32ec6174d88b7e43654a054d46d67ae2fdab/cli/snapshot/build.rs#L1-L40) [cli/build.rs#L9-60](https://github.com/denoland/deno/blob/461f32ec6174d88b7e43654a054d46d67ae2fdab/cli/build.rs#L9-L60)
- `deno compile` produces a self-contained executable by appending a virtual filesystem and metadata to a base binary: `cli/standalone/binary.rs` defines `DenoCompileBinaryWriter::write_bin` and frames the payload with `MAGIC_BYTES`, using `VfsBuilder`/`VirtualDirectory` from `deno_lib::standalone::virtual_fs`. — [cli/standalone/binary.rs#L367-420](https://github.com/denoland/deno/blob/461f32ec6174d88b7e43654a054d46d67ae2fdab/cli/standalone/binary.rs#L367-L420) [cli/standalone/binary.rs#L1619-1720](https://github.com/denoland/deno/blob/461f32ec6174d88b7e43654a054d46d67ae2fdab/cli/standalone/binary.rs#L1619-L1720) [cli/tools/compile.rs#L42-68](https://github.com/denoland/deno/blob/461f32ec6174d88b7e43654a054d46d67ae2fdab/cli/tools/compile.rs#L42-L68)
- There are two runtime binaries: the full `deno` CLI (`cli/`) and `denort` (`cli/rt_desktop`, v2.7.4) — a trimmed runtime used as the base for compiled output, with its own `binary.rs`, `file_system.rs`, and `code_cache.rs`. — [cli/rt_desktop/Cargo.toml](https://github.com/denoland/deno/blob/461f32ec6174d88b7e43654a054d46d67ae2fdab/cli/rt_desktop/Cargo.toml) [cli/rt/lib.rs](https://github.com/denoland/deno/blob/461f32ec6174d88b7e43654a054d46d67ae2fdab/cli/rt/lib.rs) [Cargo.toml#L5-10](https://github.com/denoland/deno/blob/461f32ec6174d88b7e43654a054d46d67ae2fdab/Cargo.toml#L5-L10)
- The developer entrypoint is `./x`, a shebang script running `tools/x.ts` under Deno; it exposes a `Record<string, Command>` registry with `setup`, `build`, `check`, `test-unit`, `test-node`, `test-compat`, `test-spec`, `test-core`, `test-napi`, `fmt`, `lint`, `lint-js`, `verify`, each documented with LLM-oriented help text. — [x#L1-3](https://github.com/denoland/deno/blob/461f32ec6174d88b7e43654a054d46d67ae2fdab/x#L1-L3) [tools/x.ts#L100-395](https://github.com/denoland/deno/blob/461f32ec6174d88b7e43654a054d46d67ae2fdab/tools/x.ts#L100-L395)
- GitHub Actions YAML is generated, not hand-written: every `.github/workflows/*.generated.yml` has a `.ts` sibling, `ci.ts` (2250 lines) defines runner matrices (ubuntu-24.04, ubuntu-24.04-arm, windows-2022, macos-15-intel, macos-14), a `cacheVersion` constant, and PR-label gates `ci-full`/`ci-bench`; `tools/lint.js` enforces freshness via `ensureWorkflowYmlsUpToDate()`. — [.github/workflows/ci.ts#L21-99](https://github.com/denoland/deno/blob/461f32ec6174d88b7e43654a054d46d67ae2fdab/.github/workflows/ci.ts#L21-L99) [tools/lint.js#L34-44](https://github.com/denoland/deno/blob/461f32ec6174d88b7e43654a054d46d67ae2fdab/tools/lint.js#L34-L44)
- Formatting is delegated to dprint: `tools/format.js` shells out to `npm:dprint@0.47.2` with `.dprint.json`, covering JS/TS/JSON/Markdown/TOML and Rust in one pass. — [tools/format.js#L1-22](https://github.com/denoland/deno/blob/461f32ec6174d88b7e43654a054d46d67ae2fdab/tools/format.js#L1-L22) [.dprint.json](https://github.com/denoland/deno/blob/461f32ec6174d88b7e43654a054d46d67ae2fdab/.dprint.json)
- The workspace is declared in the root `Cargo.toml` with ~80 members spanning `cli/*`, `ext/*`, `libs/*`, `runtime/*`, `tests/*` and `tools/bsdiff_helper`; `tests/sqlite_extension` is explicitly excluded because rusqlite's `loadable_extension` feature conflicts with the workspace's `session` feature. — [Cargo.toml#L1-82](https://github.com/denoland/deno/blob/461f32ec6174d88b7e43654a054d46d67ae2fdab/Cargo.toml#L1-L82)

Every claim links to its cited files at the pinned commit. Citations identify source evidence; they do not establish runtime correctness. Independent CodeVetter scan — not reviewed by upstream maintainers.

## Public product links

- [CodeVetter](https://codevetter.com/)
- [Download](https://codevetter.com/download)
- [Documentation](https://codevetter.com/docs/)
- [Source](https://github.com/Codevetter/codevetter)