-
Notifications
You must be signed in to change notification settings - Fork 5.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
refactor(unstable): deno info --json output #7417
refactor(unstable): deno info --json output #7417
Conversation
I will lint it asap and push fix. |
I think "file://[WILDCARD]/subdir/mod1.ts" key is not matching properly, I will try to figure it out but if anyone have an idea of how to fix it I will appreciate it very much. thx |
I think the problem is that files are not ordered. See #7417 (comment) |
I have left |
cli/info.rs
Outdated
#[serde(rename_all = "camelCase")] | ||
struct FileInfoVertex { | ||
size: usize, | ||
total_size: Option<usize>, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We don't show total
size of vertex in terminal output and I think we should skip it in JSON as well. It's useful to have total size of all dependencies in top level structure, but calculating sizes of subdependencies should be left to implementors. @lucacasonato WDYT?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yup I agree
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@bartossh let's remove total_size
then. Otherwise LGTM and we can land this PR
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@bartlomieju Curious about this. I requested the original feature and noticed that the total size of each dependency was left out in the end. I thought this a useful feature to see how big your dependencies were. Of course, you can compute this manually by running deno info
against each dependency but that's a bit of a pain. I agree that these should be consistent, just curious about the reasoning behind leaving out the total size of dependencies.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have implemented the change for total_size
that @bartlomieju and @lucacasonato agreed on, removing it from vertex of a flat graph, and added total_size
to module info on the top level so only total size of module will be shown.
But if you think @cknight suggestion should be applied I will cherry pic previous implementation and push changes back again.
this will look like this
Thanks
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree that these should be consistent, just curious about the reasoning behind leaving out the total size of dependencies.
Circular dependencies can be really confusing, especially if they show up multiple times. Showing only the size of singular dependency is what browsers do. If there will be huge demand for "total" size we can revisit the topic, but for now I think we should go only with size of the concrete module without it's deps.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks @bartlomieju, makes sense
@@ -374,7 +430,7 @@ mod test { | |||
} | |||
|
|||
#[test] | |||
fn get_new_prefix_adds_a_vertial_bar_if_not_is_last() { | |||
fn get_new_prefix_adds_a_vertical_bar_if_not_is_last() { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
spelling correction , not part of this feature
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, thank you @bartossh
After change It isn't causing the issue but not all dependencies are printed:
It contains cyclic dependencies https://deno.land/std/http/server.ts redirected to https://deno.land/std@0.69.0/http/server.ts, so I suppose this should to be ended like so. |
If submodule that main module is linking to contains cyclic dependencies, maybe the best way to handle the issue of not going in to a loop, is to return some informative message to the user and then end the print of a dependency tree in some nice way? Shall We open an issue for this and sort it out in a new PR or shall I sort it out in this PR? |
|
Yup. I wrote it being not specific enough. Sorry and thanks @bartlomieju for pointing this out for me with related PR example. As you see in the above example the dependency tree finishes in an ugly way. I can manage to solve this. I just have no idea what is the expected outcome. |
@bartossh it's unexpected that it stopped working - I have no problem to see whole dep tree in |
@bartlomieju it is my mistake. In the last example I have blindly copy pasted the command with
Sorry for the confusion. |
@bartossh no worries, glad it's not broken after all. I will review and land your PR today. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, thank you @bartossh
Fixes #7379
Fixes #7491