Add support for managing dependencies in deps.ts

[trivikr]

Is your feature request related to a problem? Please describe.
npm cli provides a way to manage dependencies using npm install.

• For example: npm install express

This command either adds a dependency or devDependency in package.json (documentation)

Although velociraptor is just advertised as a script runner for deno, it would be more useful if it can mange dependencies too (in deps.ts)

Describe the solution you'd like
velociraptor cli has an equivalent cli for add dependency.

• For example, vr add https://deno.land/x/oak/mod.ts

The above command could populate dependency in deps.ts

export * as oak from "https://deno.land/x/oak/mod.ts";

Describe alternatives you've considered
Manually managing dependencies in deps.ts

[trivikr]

The add command could be used to add specific versions as well.

• For example vr add https://deno.land/x/[email protected]/mod.ts

This would add [email protected]

export * as oak from "https://deno.land/x/[email protected]/mod.ts";

In future, an update command could also be added for example:

• vr update oak

Assuming latest version is [email protected], the dependency would be updated to:

export * as oak from "https://deno.land/x/[email protected]/mod.ts";

[umbopepato]

Hi @trivikr, thanks for the proposal!

Dependency/package management is a much debated aspect about deno. There's a lot of discussion going on (see for example denoland/deno#47, denoland/deno#4574, Deno may need a module.json), and some userland solutions are already starting to emerge, like module.land, udd, dedep.

With this said, I think such a dependency management layer on top of TS imports has some non-trivial implications, for instance:

• when I vr add a dependency, what members are re-exported? In your example you use a namespace export, but how do you choose the name and make sure to avoid collisions? Also, some users would probably find unacceptable having to use namespaces instead of named imports. On the other hand re-exporting everything from the module (export * from ...) loses the default export and raises the risk of name collisions.
• What if the user doesn't use/doesn't want to use the deps.ts/dev_deps.ts pattern?

Probably import maps - that module.land uses - are more suitable for this, although they're currently marked as unstable and are not 100% guaranteed to remain.

As for the update functionality, udd and dedep essentially already do this pretty well.