Glossary

Project-specific vocabulary used throughout the Deno codebase and this wiki.

Runtime concepts

deno_core — The lowest-level Rust crate (libs/core) that wraps V8 + Tokio and provides JsRuntime, ModuleLoader, the op2 macro, snapshots, and source map plumbing. Everything else builds on it.

Op (operation) — A Rust function exposed to JavaScript via the #[op2] attribute macro. Ops are the bridge between JS and the host: filesystem calls, network sockets, permission checks, etc. Naming convention: op_<area>_<verb>, e.g. op_fs_open_async.

Extension — A deno_core::Extension value declared by the deno_core::extension!(...) macro. An extension bundles: ops, ESM/script JS files, JSX/TSX bindings, and optional state initializers. Each subdirectory of ext/ is one extension crate.

Snapshot — A pre-built V8 heap that contains the parsed/initialized JS runtime code. Snapshots are produced at build time by cli/snapshot/ and runtime/snapshot.rs to make deno start in milliseconds. The HMR feature disables snapshots so you can edit JS without rebuilding.

Worker — A JavaScript execution context. The "main worker" (runtime/worker.rs::MainWorker) runs user code on the main thread; "web workers" (runtime/web_worker.rs::WebWorker) back the Worker constructor.

Bootstrap — The Rust + JS sequence that runs before user code: register globals, configure permissions, set up Deno.* namespace, install Object.defineProperty traps, etc. Driven by runtime/worker_bootstrap.rs::BootstrapOptions and runtime/js/.

JsRuntime — The core handle to a V8 isolate plus event loop, exposed by deno_core. Workers wrap a JsRuntime with permission/state plumbing.

Module loading and resolution

Module loader — The trait deno_core::ModuleLoader. The CLI's implementation lives in cli/module_loader.rs (1,668 lines) and handles HTTPS imports, npm:, jsr:, transpilation, and source map registration.

Module graph — The set of all modules reachable from an entry point, plus their dependency edges, types, and import attributes. Built and cached by cli/graph_util.rs and deno_graph (workspace dep).

Specifier — Anything that appears on the right-hand side of an import. Deno understands several specifier schemes: file:, http:/https:, npm: (npm registry), jsr: (JSR registry), and data:.

Resolver — The component that turns a raw specifier string into a fully-qualified module URL. Lives in libs/resolver (deno_resolver) for the shared algorithm and libs/node_resolver for Node-style require/conditional exports.

JSR — The JavaScript Registry at https://jsr.io. Specifiers like jsr:@std/path are resolved through cli/jsr.rs and libs/resolver.

BYONM — "Bring your own node_modules". A mode where Deno uses a hand-managed node_modules/ directory (created by npm install) instead of its own auto-managed cache. Toggled by "nodeModulesDir": "manual" in deno.json.

Permissions and security

Permission — A capability gate. Categories: read, write, net, env, sys, run, ffi, import, import_signing. Granted via --allow-* flags, denied via --deny-*, queried/requested at runtime through Deno.permissions.

PermissionsContainer — The shared, permission-aware handle threaded through the runtime (runtime/permissions/lib.rs). Every privileged op takes a &mut PermissionsContainer and calls check_* before doing the work.

Prompter — The interactive permission prompt that appears when an op is denied at runtime (runtime/permissions/prompter.rs).

Build artifacts

deno compile — Subcommand that produces a single-file executable embedding the runtime + the user's module graph. The graph is packaged as an eszip (libs/eszip) and appended to the deno binary. See Standalone binaries.

eszip — A custom archive format for module graphs (libs/eszip). Used by deno compile and by Deno Deploy.

Lockfile (deno.lock) — Records resolved versions and integrity hashes for npm, JSR, and HTTPS dependencies. Parsed/written by libs/lockfile.

deno.json / deno.jsonc — The Deno project config. Defines tasks, imports, compiler options, lint rules, fmt options, exclude lists, etc. Parsed by libs/config.

Subcommand-specific terms

Spec test — An integration test under tests/specs/<name>/ consisting of a __test__.jsonc describing a CLI invocation and either inline or .out files containing the expected output. Wildcards ([WILDCARD], [WILDLINE]) are supported.

./x — The dogfooded developer CLI for working in this repo. Source: tools/x.ts. Wraps cargo build/test/fmt/lint and runs the various test suites.

tsc snapshot — A snapshot of the bundled TypeScript compiler (cli/tsc/) used for type checking. Replaced incrementally by tsgo (TypeScript-Go), spoken to over IPC by libs/typescript_go_client.

LSP — Language Server Protocol. The deno lsp subcommand runs an LSP server out of cli/lsp/ (~1.1MB of source) consumed by the VS Code Deno extension and other editors.

HMR — Hot module replacement. A Cargo feature flag (--features hmr) that disables JS snapshots so changes to extension JS take effect without rebuilding the Rust binary.

Domains

Web platform APIs — DOM-style globals (fetch, URL, Event, MessageChannel, streams, …) implemented across ext/web, ext/fetch, ext/websocket, ext/webstorage, ext/webgpu, ext/webidl, ext/url.

Node compatibility layer — Deno's implementation of Node.js APIs. Lives primarily in ext/node (with sub-crates ext/node_crypto, ext/node_sqlite). The polyfills are JS files under ext/node/polyfills/ translating Node's node:* APIs onto Deno primitives.

WPT — Web Platform Tests, the cross-browser standards conformance suite. Runs against Deno via tests/wpt/.

KV — Deno's built-in key-value database, exposed as Deno.openKv() and implemented in ext/kv. Backed by SQLite locally or Deno Deploy remotely.

Cron — Deno.cron() scheduled jobs. Implemented in ext/cron.