denoland/deno

The CLI surface is unusually broad for a runtime: beyond `run`/`eval`/`repl`/`serve`, it ships a full npm/JSR package manager (`add`, `remove`, `install`, `outdated`, `why`, `audit`, `link`, `pack`, `publish`), a TypeScript type checker, dprint-backed formatter, deno_lint-backed linter with a JS plugin API, a test runner with leak sanitizers and coverage, a benchmarking harness, a documentation generator, a Jupyter kernel, an LSP server, a single-binary compiler, and a Deno Deploy client that bootstraps itself from JSR at runtime. Extensions in `ext/` expose the user-visible Web and Node APIs: fetch, WebSocket, WebGPU, Web Crypto, KV, Cron, FFI, N-API, and a 119-file Node polyfill tree. `deno serve` adds multi-process HTTP serving with `--parallel`, and a tunnel client can expose a local process through Deno's cluster endpoint.

• Package management is consolidated in `cli/tools/pm`, reached from `run_subcommand` for `Add`, `Audit`, `ApproveScripts`, `Remove`, `Link`, `Unlink`, and `Why`; `deno cache` is implemented as a thin alias onto `tools::installer::install_from_entrypoints`.
  cli/lib.rs#L130-190
• `deno serve` runs the module as an HTTP server with configurable parallelism: `tools::serve::serve` resolves the main module, optionally opens a browser via `open::that_detached`, and fans out to `parallelism_count(serve_flags.parallel)` workers, each labelled `[serve-worker-nn]` in console output by `99_main.js`.
  cli/tools/serve.rs#L26-80runtime/js/99_main.js#L974-987
• A module with `export default { fetch }` is auto-detected at bootstrap: `core.addMainModuleHandler` in `bootstrapMainRuntime` calls `registerDeclarativeServer`, warns when run under `deno run`, and errors when run under `deno serve` without it.
  runtime/js/99_main.js#L988-1046
• `deno deploy` does not embed the deploy client: it fetches `@deno/deploy/meta.json` from JSR at runtime, picks the latest version, and executes `jsr:@deno/deploy@<version>` in a worker with `PermissionsContainer::allow_all` plus a custom `ops::deploy::deno_deploy` extension.
  cli/tools/deploy.rs#L22-101
• The tunnel feature connects to `tunnel.global.prod.deno-cluster.net:443` (overridable via `DENO_DEPLOY_TUNNEL_ENDPOINT`), authenticates with `Authentication::App { token, org, app }`, prints 'You are connected to https://…' on `Event::Routed`, and injects the tunnel's returned metadata as process env vars.
  cli/lib.rs#L1360-1560ext/net/tunnel.rs#L32
• `deno test` supports coverage by creating the coverage dir and exporting `DENO_COVERAGE_DIR` (canonicalised) so spawned subprocesses share it; `--coverage-raw-data-only` plus `--clean` control whether prior contents are wiped.
  cli/lib.rs#L456-482cli/tools/coverage
• The test runner ships resource/op/timer leak sanitizers: `cli/tools/test/sanitizers.rs` diffs `RuntimeActivityStats` across a test, spins the event loop up to `MAX_SANITIZER_LOOP_SPINS` (16), and tracks `LeakKey::{AsyncOp,Resource,Timer,Interval}` so leaks escaping a sanitizer-ignoring test aren't misattributed to later tests.
  cli/tools/test/sanitizers.rs#L1-60cli/tools/test/mod.rs
• A Jupyter kernel is built in: `DenoSubcommand::Jupyter` routes to `tools::jupyter`, and the kernel-side JS (`40_jupyter.js`, `jupyter_kernel.js`) is lazy-loaded into the worker by `CliMainWorkerFactory::create_custom_worker` when `needs_test_modules` is set.
  cli/lib.rs#L255-258cli/worker.rs#L672-692cli/ops/jupyter.rs
• The LSP is a tower-lsp server started by `cli::lsp::start()` over stdio, with ~30 modules including `ts_server.rs` (the largest, driving TypeScript), `diagnostics.rs`, `completions.rs`, `registries.rs` for import completions, and `parent_process_checker.rs` to exit when the editor dies.
  cli/lsp/mod.rs#L1-45cli/lsp/language_server.rs#L293
• `deno publish` supports GitHub Actions OIDC: when `auth::is_gha()` and `gha_oidc_token()` are present and `DISABLE_JSR_PROVENANCE` is unset, it exchanges the Actions ID token for a `githuboidc <token>` authorization and attaches provenance.
  cli/tools/publish/mod.rs#L753-800cli/tools/publish/mod.rs#L1193-1195
• Node compatibility is the largest single extension: `ext/node` (~6 MB of source) declares `deno_core::extension!(deno_node, …)` with ops for blocklists, buffers, DNS, module hooks, and a `polyfills/` directory of 119 entries covering node:fs, node:http, node:stream, node:child_process, node:cluster, node:repl and more.
  ext/node/lib.rs#L201-230ext/node/lib.rs#L470-530
• Most node polyfills are registered as `lazy_loaded_esm` rather than eager `esm` so that non-Node `deno run` programs skip roughly 2 MB of polyfill deserialization; `node:module`, `node:process`, `node:stream`, `node:net`, `node:tty` and `node:repl` are each explicitly mapped.
  ext/node/lib.rs#L471-520
• Deno can masquerade as Node: `node_compat_shim::maybe_rewrite_node_arg0` translates Node CLI args when the binary is invoked through a `node` symlink, and `ensure_node_on_path` creates a `node` shim inside DENO_DIR and prepends it to `PATH` for subcommands that may spawn Node (e.g. Next.js Turbopack).
  cli/node_compat_shim.rs#L1-30cli/node_compat_shim.rs#L87-180cli/lib.rs#L1023-1045
• `deno task` is a real shell interpreter, not a passthrough: `cli/task_runner.rs` parses scripts with `deno_task_shell::parser::parse` and registers custom `ShellCommand` implementations — `NpmCommand`, `NpxCommand`, `NodeCommand`, `NodeGypCommand`, `DenoCommand` — that rewrite invocations back onto the current `deno` executable.
  cli/task_runner.rs#L178-230cli/task_runner.rs#L306-460
• Experimental/warned-on surfaces are explicitly labelled at dispatch: `deno bundle` prints '⚠️ deno bundle is experimental', `deno bump-version` prints a yellow experimental warning, and `deno vendor` is a hard error pointing at the Deno 1.x→2.x migration guide.
  cli/lib.rs#L161-168cli/lib.rs#L515-527