When to Use
User needs Deno expertise — secure TypeScript runtime with permissions model. Agent handles permission configuration, dependency management via URLs/npm, and migration from Node.js.
Quick Reference
| Topic | File |
|---|---|
| Permission system | permissions.md |
| Imports and dependencies | imports.md |
| Node.js migration | node-compat.md |
Permission Traps
--allow-allin development — then production crashes because you don't know what permissions you actually need--allow-readwithout path — grants access to entire filesystem, security hole--allow-runwithout list — subprocess can run anything, specify:--allow-run=git,npm--allow-envwithout list — leaks all env vars, specify:--allow-env=API_KEY,DATABASE_URL--allow-netwithout list — can connect anywhere, specify hosts:--allow-net=api.example.com- Missing permission in CI — hangs waiting for prompt that never comes, add
--no-prompt
Import Traps
- Remote URLs in production — network failure = app won't start, vendor dependencies locally
- No lockfile by default — deps can change between runs, always use
deno.lock @^1.0.0semver syntax doesn't exist — use exact URLs or import maps- Import maps in wrong place — must be in
deno.json, not separate file (Deno 2.x) - HTTPS required — HTTP imports blocked by default, most CDNs work but self-hosted may not
- URL typo — no error until runtime when import fails
TypeScript Traps
.tsextension required in imports — model generates extensionless imports that failtsconfig.jsonpaths ignored — Deno uses import maps indeno.json, not tsconfig- Type-only imports — must use
import typeor bundler may fail - Decorators — experimental, different from tsc behavior
/// <reference>— handled differently than tsc, may be ignored
Deployment Traps
deno compileincludes runtime — binary is 50MB+ minimum--cached-onlyrequires prior cache — fresh server needsdeno cachefirst- Deno Deploy limitations — no filesystem, no subprocess, no FFI
- Environment variables — different API:
Deno.env.get("VAR")notprocess.env.VAR - Signals —
Deno.addSignalListenernotprocess.on("SIGTERM")
Testing Traps
Deno.testdifferent from Jest — nodescribe, different assertions- Async test without await — test passes before promise resolves
- Resource leaks — tests fail if you don't close files/connections
- Permissions in tests — test may need different permissions than main code
- Snapshot testing — format differs from Jest snapshots
npm Compatibility Traps
npm:specifier — works for most packages but native addons failnode:specifier required —import fs from 'fs'fails, needimport fs from 'node:fs'node_modulesoptional — enable with"nodeModulesDir": truein deno.jsonpackage.jsonscripts — not automatically supported, use deno.json tasks- Peer dependencies — handled differently, may get wrong versions
Runtime Differences
Deno.readTextFilevsfs.readFile— different API, different error typesfetchis global — no import needed, unlike Node 18-- Top-level await — works everywhere, no wrapper needed
- Permissions at runtime — can request dynamically but user must approve