Deno: Provide JS API to dependency information

[ry]

Currently "deno info https://deno.land/std/http/file_server.ts" will display a dependency graph of the specified module. It would be nice to be able to access this information in a programmatic way.

let depTree = await Deno.deps("https://deno.land/std/http/file_server.ts")

Where depTree would be some JSON encodable object similar to the current output.

The first step to exposing this would be pure rust functionality of turning a Deps structure into a JSON string: https://github.com/denoland/deno/blob/960ee5257a7b38c6b3b59a3dca670c7c1771996f/cli/modules.rs#L188

[fewf]

I'm looking into implementing this

[fewf]

took me a sec to get started on this--sorry!

@ry when we spoke, i think we considered that the JSON structure could be a nested array like:

[
  [
    "dep1", [
      ["subdep1", [["subsubdep1", []]],
      ["subdep2", []]
    ]
  ],
  [
    "dep2", []
  ]
]

but I'm think it might be better as a nested object, like:

{
  dep1: {
    subdep1: {
      subsubdep1: {}
    },
    subdep2: {}
  },
  dep2: {}
}

what do you think?

[ry]

Yeah that works.. My only concern is that the ordering of the imports would be lost - but that might be recoverable from the object anyway(?) also the ordering of the imports is not very important info...

[zekth]

Depends on how you parse the deps but the order may not be lost. Also i vote for nested objects

[kt3k]

I like the array version because it's easier for typing and probably easier for interacting with programs.

[fewf]

looks like Array is winning the race. i agree with the logic that says the array version can be converted to the object version, but not vice versa. i'll go ahead with that.

[zekth]

looks like Array is winning the race. i agree with the logic that says the array version can be converted to the object version, but not vice versa. i'll go ahead with that.

a little util to parse it from array to object may be added to deno_std or deno_lib

[fewf]

PR to start out: https://github.com/denoland/deno/pull/2223

again, been hard to find time to focus on this, and I have some stashed work toward getting it to pretty format the json that I spent a bit too much on.

[ry]

I left a comment in #2223 outlining how to get started the second part of this: op_deps for @fewf.

Ref: https://github.com/denoland/deno/pull/2223#issuecomment-487309747

[KSXGitHub]

Why must it be nested? I think a shallow array/table would be simpler to analyze in most use cases.

[KSXGitHub]

@hayd I see you reacted with a "confused" emoji, I will assume that you actually meant it (BTW, you should just ask next time, because GitHub does not notify me of emoji).

A nested array is hard to traverse, a nested object is even more so (for object lacks array methods). Using nested object/array would force every code that uses Deno.deps to use a complex recursive algorithm.

A shallow array/object is like an SQL table, easy to traverse, easy to filter, easy to lookup.

There's also shared dependencies. A nested tree will duplicate shared subtrees while a table will not.

[KSXGitHub]

Out of curiosity, how many places this struct had been used?

[hayd]

For my usecase it'll be useful to have access to just the top level deps i.e. not the nested stuff.

It seems reasonable to configure the output with options e.g. flatten (so users don't need to reproduce the flattening code)... Or perhaps Deps helper functions could be added to std...

An alternative is Deps be a class and define an iteration method over all deps. That has the benefit of being more explicit than json (though you can have a .json method).

[KSXGitHub]

For my usecase it'll be useful to have access to just the top level deps i.e. not the nested stuff.

I think just having access to top level deps is good enough. User can always call Deno.deps again to get more.

It seems reasonable to configure the output with options e.g. flatten (so users don't need to reproduce the flattening code)... Or perhaps Deps helper functions could be added to std...

It might be tempting to expose functionality that Rust code already have, but that would add another burden of backward compatibility on Deno core, making it hard to change in the future. Top level deps only is enough.

[hayd]

Is the way to do this via an op, something like op_deps ?

[kitsonk]

We now have deno info --json which is effectively what this should be in the runtime, but we have #7927 which needs to occur and will be a breaking change. This could be addressed after #7927 is resolved.