Deno
Use Deno as the default runtime/tooling when the repo contains deno.json/deno.jsonc, uses deno.lock, or scripts/documentation reference deno task, deno run, deno test, etc.
Quick decision rules
- Prefer
deno task <name>if the repo defines tasks. - Use
deno add/deno removeto manage dependencies (writes to config). - Be explicit about permissions for
deno run/deno test.
Common operations
Initialize a new project
deno initAdd dependencies (JSR and npm)
# JSR (recommended for Deno-first packages)
deno add jsr:@std/path
# npm packages are supported too
deno add npm:react
# multiple at once
deno add jsr:@std/assert npm:chalkRemove dependencies
deno remove jsr:@std/pathRun a script
# Minimal permissions: only what the program needs
# Examples:
# --allow-net=api.example.com
# --allow-read=./data
# --allow-env=FOO,BAR
deno run --allow-net --allow-read main.tsRun tasks
# list tasks
deno task
# run a task defined in deno.json/deno.jsonc
deno task devFormatting, linting, testing
deno fmt
deno lint
deno test
# common permissioned test run
deno test --allow-net --allow-readInstall / run CLIs
# Run a JSR or npm package's CLI without installing globally
deno x jsr:@std/http/file-server -p 8080
# Install globally (requires choosing permissions at install time)
# Prefer the smallest set of permissions; avoid blanket flags unless necessary.
deno install -g -N -R jsr:@std/http/file-server -- -p 8080Notes / pitfalls
- Deno is secure-by-default: missing permissions cause runtime errors; add the smallest set of
--allow-*flags needed. - Dependency specifiers:
- jsr: for JSR registry packages - npm: for npm packages - URL imports are also supported (and cached)
- Lockfile:
deno.lockhelps ensure reproducible dependency resolution.