search

denoland / deno

A modern runtime for JavaScript and TypeScript.
https://deno.com
MIT License
93.92k stars 5.22k forks source link

Separate `deno graph` from `deno info` #10628

Open nayeemrmn opened 3 years ago

nayeemrmn commented 3 years ago

The deno info subcommand should only output cache info and for a single module at a time. We should have a separate deno graph subcommand for outputting the dependency graph of a module.

  1. The use cases for these two things are entirely separate. A large list of dependencies creates a lot of noise to sift through when you are just trying to get the location of a cache file. You never need both of these things at once.
  2. It allows more versatility for deno info. I propose that deno info doesn't implicitly invoke deno cache (which it would no longer need to), and should show null cache file paths for uncached modules. You can instead call deno cache <url> && deno info <url> for the current behaviour. This design can be applied to query the state of the cache, which partially satisfies feature requests like #5600.

This would be a 2.0 change.

nayeemrmn commented 3 years ago

This would be a 2.0 change.

It has occurred to me that the output of deno info mod.ts is merely pretty-print... and the API access deno info --json mod.ts is still marked as unstable... it's a strong argument for permitting this change in a minor release with some provisions.

Other than the proposed change the --cert, --import-map, --reload flags would be noop'd and hidden until 2.0 removal.

What do you think? @ry @kitsonk

bartlomieju commented 5 months ago

We should do it as deno info --dont-recurse. @nayeemrmn do you want to take this up?