Dependencies, JSR, and npm
Manage JSR, npm, Node built-ins, imports, deno.lock, and the cache
Add dependencies
deno install jsr:@std/assert
deno install npm:express
Since Deno 2.8, an unprefixed CLI package name defaults to npm, so deno install express equals deno install npm:express. Import specifiers still need npm: unless mapped by imports or package.json; JSR packages remain explicit as jsr: in the CLI.
The command updates imports in deno.json, allowing mapped names in code:
import { assertEquals } from "@std/assert";
import express from "express";
import { readFile } from "node:fs/promises";
Four sources of project state
| Location | Responsibility |
|---|---|
deno.json(c) | import mappings, tasks, workspace, and tool settings |
package.json | npm scripts/dependencies and Node ecosystem metadata; may coexist |
deno.lock | resolved versions and integrity; commit it |
Deno cache / node_modules | local materialization, not the review source of truth |
CI should use the committed lockfile and fail on inconsistent resolution. Do not hide resolution conflicts by deleting it.
deno ci # Deno 2.8+: require lockfile, wipe node_modules, frozen install
deno ci --prod # skip package.json devDependencies
Choose a source
- Preserve the repository's existing source and import conventions.
- Check JSR first for TypeScript-native libraries and the standard library.
- Use npm for Node ecosystem packages; spell built-ins with
node:. - URL imports can pin web modules, but team projects usually centralize them through
imports. - Deno 2.9 adds
deno listfor declared dependencies anddeno link/unlinkfor local package links.
When resolution fails, use deno info to inspect the graph and cache before checking proxies, private registries, and certificates.
Official references: Modules and dependencies and Packages.