# Ecosystem decisions

## 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

1. Is the target Deno CLI, Deno Deploy, browsers, or multiple platforms?
2. Does a dependency require Node-API, postinstall, `node_modules`, or system libraries?
3. Does the team already have framework expertise and observability integration?
4. Can permissions be scoped to exact hosts, paths, and variables?
5. 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](https://jsr.io), [npm compatibility](https://docs.deno.com/runtime/fundamentals/node/), and [Fresh](https://fresh.deno.dev).