deno vendor: Vendoring Dependencies
deno vendor copies a module graph's remote dependencies into a local vendor/ directory for offline, reproducible builds.
Vendoring commits dependencies into the repo so CI needs no network. The mechanism moved from a subcommand in Deno 1 to a config option in Deno 2.
What it does
In Deno 1, deno vendor <entry> downloaded the graph into vendor/ and emitted an import map to use it. In Deno 2 the standalone subcommand was removed in favor of "vendor": true in deno.json, which writes the same vendor/ folder during install/cache. Either way, builds then run without fetching.
Common usage
# Deno 1 style
deno vendor main.ts
deno run --import-map=vendor/import_map.json main.ts
# Deno 2 style: set "vendor": true in deno.json, then
deno install
deno run main.tsOptions
| Item | What it does |
|---|---|
| <entry> (Deno 1) | Module(s) whose dependencies to vendor |
| --force (Deno 1) | Overwrite an existing vendor directory |
| "vendor": true (Deno 2) | Enable vendoring in deno.json |
| --import-map (Deno 1) | Use the generated map when running |
In CI
Commit the vendor/ directory so the pipeline runs fully offline with no DENO_DIR restore needed. On Deno 2, set "vendor": true in deno.json and run deno install; on Deno 1, run deno vendor and pass --import-map. Pin the Deno version so the mechanism matches.
Common errors in CI
"error: unrecognized subcommand 'vendor'" means you are on Deno 2, where vendoring is the deno.json "vendor": true option rather than a subcommand. "Module not found" after vendoring means the import map or vendor path is not wired up. Stale vendored files cause mismatches; re-vendor after changing dependencies.