deno cache --vendor does not let me choose a folder name

[andreas-wagner]

Running deno cache --vendor deps.ts basically sets vendor to true and generates a "vendor" folder.

The problem is, that this "vendor" folder then sits in the middle of all my other source code folders, as I am not using a "src" folder or something like that.

It'd be nice to keep the functionality of deno vendor --output=./_vendor, where I can specify the target folder for vendoring into.

Example: deno cache --vendor=./_vendor deps.ts

This helps to keep things nice and tidy and also to keep my existing tooling, which I build up over the last 3 years of using Deno...

deno --version
deno 1.45.2 (release, x86_64-apple-darwin)
v8 12.7.224.12
typescript 5.5.2

[nktpro]

I'd like to second this. We have depended heavily on deno vendor ... to build offline-only Deno apps for distributions where deno compile does not fit due to its lack of support for dynamic imports.

In certain use cases, the packaged Deno app still needs to dynamically import and interact with user-provided modules. Currently, the only way to nicely package those apps is via the following workflow:

1. Vendor all dependencies using deno vendor
2. Eliminate all remote dependencies by transpiling the source files and rewrite all imports/exports to reference the locally-vendored dependencies from step 1.

This works nicely thanks to 2 important features deno vendor does:

• It allows outputting to a custom vendor directory outside the source tree. In a CI pipeline, this is simply a temp dir.
• It generates a corresponding import_map.json file such that the build tool can traverse and rewrite imports/exports during transpilation.

The outcome is an offline-ready bundle, the entrypoint of which can still be executed via deno run ... behind the scene, but still supporting importing dynamic user-provided modules. The beauty is that those additional dynamic modules can still have their own Deno env setup and remote dependencies independently from the app's original dependencies (which are already hard-wired via the combination of vendoring + rewriting import/export specifiers).

It's a concern to lose deno vendor via hard deprecation in the upcoming Deno 2.x before the alternative CLI interfaces provide equivalent functionalities.