Use when building applications with Deno, the TypeScript-first runtime with built-in security, web standard APIs, and modern tooling. Covers Deno 2.x features, permissions, module system, standard library, built-in tools, HTTP servers, testing, npm compatibility, Deno Deploy, KV, and frameworks.
USE FOR: Deno runtime projects, TypeScript-first server-side development, secure sandboxed execution, edge functions with Deno Deploy, key-value storage with Deno KV, Fresh or Oak web applications, scripts leveraging web standard APIs, npm-compatible Deno projects, Deno 2.x migrations
DO NOT USE FOR: Node.js-only projects without Deno compatibility (use express or nestjs), frontend-only React/Vue/Angular apps (use nextjs or relevant framework skill), Bun-specific tooling, Cloudflare Workers-specific bindings (use hono)
Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.
Une commande directe contourne le prompt de vérification. Examinez la source avant de l'exécuter.
Use when building applications with Deno, the TypeScript-first runtime with built-in security, web standard APIs, and modern tooling. Covers Deno 2.x features, permissions, module system, standard library, built-in tools, HTTP servers, testing, npm compatibility, Deno Deploy, KV, and frameworks.
USE FOR: Deno runtime projects, TypeScript-first server-side development, secure sandboxed execution, edge functions with Deno Deploy, key-value storage with Deno KV, Fresh or Oak web applications, scripts leveraging web standard APIs, npm-compatible Deno projects, Deno 2.x migrations
DO NOT USE FOR: Node.js-only projects without Deno compatibility (use express or nestjs), frontend-only React/Vue/Angular apps (use nextjs or relevant framework skill), Bun-specific tooling, Cloudflare Workers-specific bindings (use hono)
[{"title":"Deno Documentation","url":"https://docs.deno.com"},{"title":"Deno GitHub Repository","url":"https://github.com/denoland/deno"},{"title":"Deno Standard Library","url":"https://jsr.io/@std"}]
Deno
Overview
Deno is a modern runtime for JavaScript and TypeScript created by Ryan Dahl (the original creator of Node.js). It runs TypeScript natively without a build step, is secure by default with an explicit permissions system, and embraces web standard APIs (fetch, Request, Response, Web Crypto, Streams, etc.) as first-class citizens. Deno 2.x brings full backward compatibility with Node.js and npm, making it a practical drop-in alternative for existing projects while offering a more secure and ergonomic developer experience.
Key Characteristics
Feature
Description
TypeScript-first
Runs .ts and .tsx files natively -- no tsc, ts-node, or build step required
Secure by default
No file, network, or environment access unless explicitly granted via permission flags
Web standard APIs
Uses fetch, Request, Response, URL, ReadableStream, WritableStream, crypto.subtle, and more
Built-in tooling
Formatter (deno fmt), linter (deno lint), test runner (deno test), bundler, documentation generator, and more
Single executable
Ships as a single binary with no external dependencies
npm compatibility
Deno 2.x supports npm: specifiers, package.json, and node_modules for full Node.js ecosystem access
Deno 2.x Features
Deno 2.x is a major release focused on backward compatibility with the Node.js and npm ecosystem while retaining Deno's security model and developer experience improvements.
Feature
Details
npm/Node compatibility
Import any npm package via npm: specifier or package.json dependencies
package.json support
Deno reads package.json for dependencies, scripts, and configuration
deno.json
Project configuration file for imports, compiler options, tasks, formatting, linting, and more
Long Term Support
LTS releases for production stability
Stabilized APIs
Deno.serve, Deno.openKv, Deno.cron, and other APIs moved to stable
Workspaces
Monorepo support via deno.json workspaces field
JSR registry
First-class support for the JavaScript Registry (jsr.io) for publishing and consuming packages
Private npm registries
Support for private npm registries via .npmrc
Configuration
deno.json / deno.jsonc
The deno.json (or deno.jsonc with comments) file is the central configuration file for Deno projects.
{// Compiler options (subset of tsconfig.json compilerOptions)"compilerOptions":{"strict":true,"jsx":"react-jsx","jsxImportSource":"preact","lib":["deno.window","deno.unstable"],"noImplicitReturns":true,"noFallthroughCasesInSwitch":true},// Import map (inline) -- maps bare specifiers to URLs or npm packages"imports":{"@std/assert":"jsr:@std/assert@^1","@std/path":"jsr:@std/path@^1","@std/http":"jsr:@std/http@^1","oak":"jsr:@oak/oak@^17","zod":"npm:zod@^3","express":"npm:express@^4"},// Alternative: external import map file// "importMap": "./import_map.json",// Task runner (like npm scripts)"tasks":{"dev":"deno run --watch --allow-net --allow-read --allow-env main.ts","start":"deno run --allow-net --allow-read --allow-env main.ts","test":"deno test --allow-read --allow-net","lint":"deno lint","fmt":"deno fmt","check":"deno check main.ts","compile":"deno compile --allow-net --allow-read --output server main.ts"},// Formatter configuration"fmt":{"useTabs":false,"lineWidth":100,"indentWidth":2,"semiColons":true,"singleQuote":false,"proseWrap":"preserve","include":["src/"],"exclude":["vendor/"]},// Linter configuration"lint":{"include":["src/"],"exclude":["generated/"],"rules":{"tags":["recommended"],"include":["no-unused-vars","eqeqeq"],"exclude":["no-explicit-any"]}},// Test configuration"test":{"include":["tests/","src/**/*_test.ts"],"exclude":["tests/fixtures/"]},// Publish configuration (for JSR)"publish":{"include":["src/","README.md","deno.json"],"exclude":["src/testdata/"]},// Node modules directory (opt-in for npm compatibility)"nodeModulesDir":"auto",// Workspaces for monorepos"workspace":["./packages/core","./packages/cli"],// Lock file (enabled by default)"lock":true}
Permissions System
Deno is secure by default. All access to the file system, network, environment variables, subprocesses, and foreign function interfaces must be explicitly granted. Permissions are specified as CLI flags when running a script.
Permission Flags
Flag
Description
Granular Example
--allow-read
File system read access
--allow-read=/tmp,./data
--allow-write
File system write access
--allow-write=./output,/tmp
--allow-net
Network access
--allow-net=api.example.com,localhost:8080
--allow-env
Environment variable access
--allow-env=DATABASE_URL,API_KEY
--allow-run
Subprocess execution
--allow-run=git,deno
--allow-ffi
Foreign function interface
--allow-ffi=./libcrypto.so
--allow-sys
System information access
--allow-sys=osRelease,hostname
--allow-hrtime
High-resolution time
(no granular options)
--allow-all / -A
Grant all permissions
(use only for development)
--deny-read
Explicitly deny read access
--deny-read=/etc
--deny-write
Explicitly deny write access
--deny-write=/
--deny-net
Explicitly deny network access
--deny-net=evil.com
Permission Examples
# Minimal permissions for a web server
deno run --allow-net=:8000 --allow-read=./static --allow-env=PORT server.ts
# Script that reads files and writes output
deno run --allow-read=./input --allow-write=./output transform.ts
# Development with all permissions
deno run -A main.ts
# Deny specific paths while allowing general access
deno run --allow-read --deny-read=/etc/passwd script.ts
Runtime Permission Requests
// Request permissions at runtimeconst status = awaitDeno.permissions.request({ name: "read", path: "./data" });
if (status.state === "granted") {
const data = awaitDeno.readTextFile("./data/config.json");
}
// Query current permission stateconst netPerm = awaitDeno.permissions.query({ name: "net", host: "api.example.com" });
console.log(netPerm.state); // "granted" | "denied" | "prompt"// Revoke a permissionawaitDeno.permissions.revoke({ name: "read", path: "./data" });
Module System
URL Imports
// Import directly from URLsimport { serve } from"https://deno.land/std@0.224.0/http/server.ts";
// Import from JSR (recommended)import { assert } from"jsr:@std/assert@^1";
// JSR (jsr.io) is the modern registry for Deno and other runtimes// Import from JSR in deno.json:// "imports": { "@std/assert": "jsr:@std/assert@^1" }// Or import directly:import { assertEquals } from"jsr:@std/assert@^1";
import { Hono } from"jsr:@hono/hono@^4";
// Publish to JSR:// deno publish
Standard Library (@std/)
Deno's standard library is available on JSR under the @std scope. It provides reviewed, high-quality modules for common tasks.
Key @std Modules
Module
Import
Purpose
@std/fs
jsr:@std/fs
File system utilities (walk, ensureDir, copy, move, exists)
Deno ships with a comprehensive set of built-in development tools that require no additional installation.
Command
Purpose
Example
deno fmt
Format TypeScript, JavaScript, JSON, and Markdown files
deno fmt src/
deno lint
Lint source files with built-in rules
deno lint src/
deno test
Run tests
deno test --allow-read
deno bench
Run benchmarks
deno bench bench/
deno doc
Generate documentation from JSDoc comments
deno doc mod.ts
deno compile
Compile to a standalone executable
deno compile --output app main.ts
deno serve
Serve an HTTP handler with automatic parallelism
deno serve --port 8000 main.ts
deno task
Run a task defined in deno.json
deno task dev
deno jupyter
Deno kernel for Jupyter notebooks
deno jupyter --install
deno check
Type-check without running
deno check main.ts
deno info
Show dependency tree and cache info
deno info main.ts
deno install
Install a script as a command or manage dependencies
deno install
deno publish
Publish a package to JSR
deno publish
deno coverage
Generate coverage reports from test runs
deno coverage ./cov_profile
deno init
Scaffold a new Deno project
deno init my_project
deno add
Add a dependency to deno.json
deno add jsr:@std/assert
deno remove
Remove a dependency from deno.json
deno remove @std/assert
deno fmt
# Format all supported files in the project
deno fmt# Check formatting without modifying files
deno fmt --check
# Format specific files or directories
deno fmt src/ main.ts
# Format stdinecho' const x=1' | deno fmt -
deno lint
# Lint all TypeScript/JavaScript files
deno lint
# Lint specific files
deno lint src/main.ts src/utils.ts
# List available rules
deno lint --rules
deno test
# Run all tests
deno test# Run with permissions
deno test --allow-read --allow-net
# Run specific test files
deno test tests/user_test.ts
# Filter tests by name
deno test --filter "should parse"# Run with coverage
deno test --coverage=cov_profile
deno coverage cov_profile --lcov > coverage.lcov
# Watch mode
deno test --watch
// main.ts -- export a default object with a fetch handlerexportdefault {
fetch(request: Request): Response {
returnnewResponse("Hello from Deno.serve!");
},
};
# Serve with automatic parallelism across CPU cores
deno serve --port 8000 main.ts
# Serve with specific number of workers
deno serve --parallel --port 8000 main.ts
// deno.json -- opt into node_modules directory{"nodeModulesDir":"auto"}
# Install dependencies from package.json into node_modules
deno install
# Or run directly (Deno creates node_modules automatically with nodeModulesDir: "auto")
deno run --allow-net --allow-read --allow-env main.ts
Node API Polyfills
Deno provides polyfills for most Node.js built-in modules:
Node Module
Support
Notes
node:fs / node:fs/promises
Full
File system operations
node:path
Full
Path manipulation
node:http / node:https
Full
HTTP server and client
node:crypto
Full
Cryptographic functions
node:buffer
Full
Buffer class
node:stream
Full
Stream classes
node:events
Full
EventEmitter
node:process
Full
Process object and env
node:os
Full
OS information
node:util
Full
Utility functions
node:url
Full
URL parsing
node:net
Full
TCP networking
node:child_process
Full
Subprocess management
node:worker_threads
Full
Worker threads
node:assert
Full
Assertion testing
Deno Deploy
Overview
Deno Deploy is an edge computing platform that runs Deno code globally on V8 isolates. It provides zero-config deployments, automatic HTTPS, and globally distributed execution.
Edge Functions with Deno.serve
// main.ts -- deployed to Deno DeployDeno.serve((req: Request) => {
const url = newURL(req.url);
if (url.pathname === "/api/hello") {
returnResponse.json({
message: "Hello from the edge!",
region: Deno.env.get("DENO_REGION"),
});
}
returnnewResponse("Not Found", { status: 404 });
});
Deno KV on Deploy
// KV is available on Deno Deploy with automatic global replicationconst kv = awaitDeno.openKv();
Deno.serve(async (req: Request) => {
const url = newURL(req.url);
if (req.method === "GET" && url.pathname === "/api/visits") {
const entry = await kv.get(["visits"]);
returnResponse.json({ visits: entry.value ?? 0 });
}
if (req.method === "POST" && url.pathname === "/api/visits") {
await kv.atomic()
.sum(["visits"], 1n)
.commit();
returnResponse.json({ incremented: true });
}
returnnewResponse("Not Found", { status: 404 });
});
BroadcastChannel on Deploy
// Cross-isolate communication on Deno Deployconst channel = newBroadcastChannel("chat");
channel.onmessage = (event: MessageEvent) => {
console.log("Received:", event.data);
};
Deno.serve(async (req: Request) => {
if (req.method === "POST") {
const body = await req.json();
channel.postMessage(body);
returnResponse.json({ sent: true });
}
returnnewResponse("Send a POST request");
});
Deno KV is a built-in key-value store that works both locally (backed by SQLite) and on Deno Deploy (globally replicated). Keys are arrays of Deno.KvKeyPart values (strings, numbers, booleans, Uint8Arrays, bigints).
const kv = awaitDeno.openKv();
// Watch for changes to specific keysconst stream = kv.watch([
["config", "feature_flags"],
["config", "maintenance_mode"],
]);
forawait (const entries of stream) {
const [flags, maintenance] = entries;
console.log("Feature flags:", flags.value);
console.log("Maintenance mode:", maintenance.value);
}
Fresh Framework
Overview
Fresh is Deno's official full-stack web framework. It uses Islands Architecture for selective client-side hydration, Preact for rendering, and file-based routing. Pages are server-rendered by default with zero JavaScript shipped to the client unless an Island component is used.
Oak is a middleware framework for Deno inspired by Koa (and Express). It provides a familiar middleware pipeline, router, and request/response abstractions for building HTTP servers.
Full via npm: specifier and package.json (Deno 2.x)
Native
Native
Built-in formatter
deno fmt (Prettier-compatible)
None (use Prettier)
None (use Prettier)
Built-in linter
deno lint
None (use ESLint)
None (use ESLint)
Built-in test runner
deno test
node --test (basic)
bun test (Jest-compatible)
Built-in benchmarking
deno bench
None
None
HTTP server
Deno.serve (web standard)
http.createServer or frameworks
Bun.serve
Web standard APIs
Comprehensive (fetch, WebSocket, Web Crypto, Streams)
Partial (fetch in v18+, Web Crypto)
Comprehensive
Cold start time
Fast
Moderate
Fastest
Edge/Deploy platform
Deno Deploy
Various (Vercel, AWS Lambda, etc.)
None (self-hosted)
Key-value store
Built-in Deno KV
None built-in
Built-in Bun SQLite
Single executable compile
deno compile
pkg, nexe, or SEA (Node 20+)
bun build --compile
Ecosystem size
Full npm access + JSR
Largest (npm)
Full npm access
REPL
deno (with TypeScript)
node
bun
Jupyter support
deno jupyter
Via third-party kernels
None
When to Choose Deno Over Node.js
You want native TypeScript with zero build configuration.
Security is a priority and you need sandboxed execution with explicit permissions.
You prefer web standard APIs (fetch, Request, Response, Streams) over Node-specific APIs.
You want built-in formatting, linting, and testing without installing additional tools.
You are deploying edge functions to Deno Deploy.
You need a built-in key-value store (Deno KV).
You want URL-based imports and a single lockfile without node_modules (optional).
When to Choose Node.js Over Deno
Your project has deep dependencies on Node.js-specific APIs or native addons (.node files).
You need maximum compatibility with the npm ecosystem (though Deno 2.x closes this gap significantly).
Your team and deployment infrastructure are built around Node.js tooling.
You rely on Node.js-specific frameworks like Express middleware ecosystem or NestJS decorators.
When to Choose Bun Over Deno
Raw startup speed and throughput are the top priority.
You want the fastest possible package manager for large node_modules.
You need a Jest-compatible test runner with minimal migration.
Best Practices
Use explicit permissions -- always specify the minimum required permissions instead of using --allow-all in production. Use granular paths and hosts.
# Production
deno run --allow-net=api.example.com:443 --allow-read=./config --allow-env=DATABASE_URL server.ts
Use deno.json for project configuration -- centralize imports, tasks, compiler options, and tool settings in a single configuration file.
Prefer JSR (jsr:) over URL imports -- the JSR registry provides versioned, documented packages with TypeScript-first support. Use deno add to manage dependencies.
deno add jsr:@std/assert jsr:@oak/oak
Use import maps for bare specifiers -- define import maps in deno.json to avoid verbose URLs in source code.
Use Deno.serve for HTTP servers -- it provides automatic parallelism, follows web standards, and is the recommended HTTP server API.
Run deno fmt and deno lint in CI -- use the built-in formatter and linter as part of your continuous integration pipeline.
Use deno check for type checking -- run type checking separately from execution, especially in CI pipelines.
Lock dependencies -- use the built-in lock file (deno.lock) to ensure reproducible builds. It is enabled by default.
Use using declarations for resource management -- Deno supports the TC39 Explicit Resource Management proposal for automatic cleanup.
using file = awaitDeno.open("./data.txt");
// file is automatically closed when scope exits
Prefer @std/ modules over third-party alternatives -- the standard library is reviewed, tested, and maintained by the Deno team.
Use Deno KV for simple data persistence -- it works locally (SQLite) and on Deno Deploy (globally replicated) with the same API.
Use deno compile for distribution -- compile your application to a self-contained executable for easy deployment without requiring the Deno runtime on the target machine.
Structure tests alongside source files -- Deno conventionally uses _test.ts suffix or a tests/ directory. Use deno test --coverage to track coverage.
Use deno task instead of Makefiles or npm scripts -- define project tasks in deno.json for a consistent developer experience.
Migrate from Node.js incrementally -- Deno 2.x supports package.json and node_modules, so you can migrate existing projects file by file while keeping npm dependencies working.
