Ecosystem decisions
Choose among JSR/npm, native APIs, Fresh, and Node frameworks from explicit constraints
Dependency source
| Need | Lean toward | Check |
|---|---|---|
| TypeScript-native package or standard library | JSR | exports, docs, version policy |
| Mature Node ecosystem package | npm | Node APIs, install scripts, native addons |
| Small HTTP service | Deno.serve + Web APIs | whether routing, auth, or validation needs a framework |
| Deno-native full stack | Fresh | current version, islands, deployment target |
| Existing Express/Hono-style app | keep framework first | tests and deployment adapter |
Decision questions
- Is the target Deno CLI, Deno Deploy, browsers, or multiple platforms?
- Does a dependency require Node-API, postinstall,
node_modules, or system libraries? - Does the team already have framework expertise and observability integration?
- Can permissions be scoped to exact hosts, paths, and variables?
- Are package maintenance, licensing, publisher, and supply-chain risk acceptable?
There is no rule that a Deno project must use only Deno-native packages. Preserve existing architecture, use tests to establish compatibility, and replace dependencies only when maintenance cost justifies it.
Official entry points: JSR, npm compatibility, and Fresh.