Mental model

Understand the boundaries among the Deno runtime, permissions, modules, cache, and built-in tools

View Markdown Upstream source

Deno in one diagram

source (.ts/.js/.wasm)
  ├─ modules: local / JSR / npm / URL
  ├─ config: deno.json(c) + deno.lock
  ├─ tools: fmt / lint / check / test / doc / compile
  └─ runtime: Web APIs + Deno APIs + Node compatibility
                    ↓
       permission boundary (--allow-* / --deny-*)
                    ↓
       files, network, environment, subprocesses, FFI

Three important differences from Node.js

Secure defaults: sensitive I/O is denied until granted, and grants can be scoped to paths, hosts, or variable names.
Direct TypeScript execution: execution transpiles TypeScript but does not imply a full type-check on every run; keep deno check in CI.
One toolchain: formatting, linting, testing, and docs ship with the same CLI version.

Dependencies have multiple sources

JSR packages use jsr: and work well for TypeScript-native packages and the Deno standard library.
npm packages use npm:; Node built-ins use node:.
imports in deno.json maps full specifiers to stable bare import names.
deno.lock pins resolution and integrity data and should be committed.

Continue with Permissions and Dependencies.