Deno 2.x capability matrix
Separate stable baseline features from version-sensitive and hosted-platform behavior
This is not a minor-version changelog. It tells maintainers what can be treated as the Deno 2.x baseline and what must be queried again for the installed version.
| Capability | 2.x docs baseline | Before release |
|---|---|---|
| Direct TypeScript execution | stable | keep deno check in CI |
Permission sandbox and scoped --allow-* | stable | compare with deno help run |
JSR, npm, and node: | stable | test the actual package and native addons |
deno.json tasks/imports/workspace | stable | verify fields against current schema |
| fmt, lint, test, doc, compile | stable | verify command flags |
| Node/npm compatibility details | evolving | run real tests; do not rely on a slogan |
| Unstable APIs | not stable | record flag, version, and fallback |
| Deno Deploy, KV, Sandbox | platform capability | check current quota, region, pricing, and SLA |
Recent release milestones
| Version | Capabilities used by this site | Boundary |
|---|---|---|
| 2.6 | deno audit and minimum dependency age | scanning does not replace lockfiles or review |
| 2.8 | deno ci, audit --fix, default npm names in CLI, cross-OS/arch install | audit --fix mutates dependencies; CI uses frozen semantics |
| 2.9 | deno desktop, deno list/link/unlink, built-in test snapshots, default 24h npm age | Desktop APIs require 2.9+ and still evolve |
Use current CLI help and the Deno 2.8 and Deno 2.9 release notes for exact behavior.
Record the environment
deno --version
deno info
deno help run
Include Deno, V8, TypeScript, OS, and architecture in issues, benchmarks, and deployment reports. Before upgrades, read Deno releases and official docs, then run existing gates in staging.