Skip to content
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

Add 'meteor list --tree' to show a tree of package dependencies. #8936

merged 1 commit into from Jul 28, 2017


Copy link

@sdarnell sdarnell commented Jul 21, 2017

Add 'meteor list --tree' to show a tree of package dependencies.
There's also a --weak command line option which when specified shows weak dependencies.

See feature request: meteor/meteor-feature-requests#143

With the basic meteor list --tree it gives output very much like npm list (example below).

At the top level are the constraints from the .meteor/packages, and then for each of those it outputs the (strong) dependencies of each, expanding recursively.
Subsequent references of a package do not get expanded again. This avoids infinite recursion and an excessive amount of repetitive output.
Weak references can be show by also specifying the --weak option, but this never follows weak references. As any weakly referenced package which is present must also have a strong reference - so it gets expanded at the first strong reference.
Top level references are only every expanded at the top level rather than on first encounter, which I think makes the output more sensible.

Note that the version included in each line is version selected NOT the constraint. When expanding one level down the constraint would be better, but when you have cross references, and deeper nesting it seemed better to display the actual version selected by the constraint solver.

Here's a truncated example with --weak specified:

├── autopublish[weak] package skipped         
├── blaze[weak] package skipped               
├─┬ callback-hook@1.0.10                      
│ └── underscore@1.0.10                       
├─┬ check@1.2.5                               
│ ├─┬ ejson@1.0.13                            
│ │ ├── base64@1.0.10                         
│ │ └── underscore@1.0.10                     
│ ├─┬ modules@0.9.2                           
│ │ └── modules-runtime@0.8.0                 
│ └── underscore@1.0.10                       
├─┬ ddp@1.3.0                                 
│ ├─┬ ddp-client@2.0.0                        
│ │ ├── check@1.2.5 (expanded above)          
│ │ ├─┬ ddp-common@1.2.9                      
│ │ │ ├── check@1.2.5 (expanded above)        
│ │ │ ├── ejson@1.0.13 (expanded above)       
│ │ │ ├─┬ random@1.0.10                       
│ │ │ │ ├── ecmascript@0.8.2 (top level)      
│ │ │ │ └── underscore@1.0.10  

Thoughts for improvements:
Personally, the output with package names, versions and suffix text (e.g. 'expanded above') feels a bit cluttered. So I'm open to suggestions for making it easier to read. I did consider color or some other console highlighting but the Console class would probably need extending.
I also considered removing the versions, but you can't see them for indirectly referenced packages without delving into .meteor/versions, and if you want to dig deeper with a meteor show xxx you ideally want to specify the version.
Instead of 'expanded above' and 'top level' we could use unicode arrows or and asterisk etc., but we'd probably need to add a note at the bottom to explain otherwise people will get confused. Similarly, '[weak]' could be a ? or something, but in both cases I figured being explicit was better.

Finally, unlike the regular meteor list, I didn't add the plugin packages from projectContext.cordovaPluginsFile because I wasn't sure what they were for or how to test - are they included in the solver's answer set?
Rather than adding them to the root set, it may be best to note any packages in the 'answer' that weren't visited by walking down from the root, and just visit those explicitly at the end.

Oh, finally-finally, I used the new meteor coding style and Set/Map rather than sticking to the style of the surrounding file as it seemed separate enough, and Set/Map/Array.[map|filter|sort|every] seemed a better choice than underscore equivalents.

There's also a --weak command line option which when specified
also shows weak dependencies.
Copy link

@benjamn benjamn commented Jul 21, 2017

This is awesome!! 💥

@benjamn benjamn added this to the Release 1.5.2 milestone Jul 21, 2017
Copy link

@hwillson hwillson commented Jul 26, 2017

This is really great @sdarnell!

Personally, the output with package names, versions and suffix text (e.g. 'expanded above') feels a bit cluttered.

Maybe something like this (where the legend is included in the list output)?

▲ = already expanded above
◀ = already expanded in the top level
~ = weak dependency

├─┬ babel-compiler@6.19.4                     
│ └─┬ ecmascript-runtime@0.4.1                
│   ├─┬ ecmascript-runtime-client@0.4.3       
│   │ ├── es5-shim@4.6.15[~] ◀   
│   │ ├── modules@0.9.2 ▲      
│   │ └─┬ promise@0.8.9                       
│   │   └── modules@0.9.2 ▲    
│   └─┬ ecmascript-runtime-server@0.4.1       
│     ├── es5-shim@4.6.15[~] ◀   
│     ├── modules@0.9.2 ▲      
│     └── promise@0.8.9 ▲      
├─┬ babel-runtime@1.0.1                       
│ ├── es5-shim@4.6.15[~] ◀       
│ ├── modules@0.9.2 ▲          
│ └── promise@0.8.9 ▲          
├── ecmascript-runtime@0.4.1 ▲ 
├── modules@0.9.2 ▲            
└── promise@0.8.9 ▲            
└── modules@0.9.2 ▲  
Copy link

@hwillson hwillson left a comment

I love this! I've been testing and everything works well. Approving as I think this could be merged as is; any changes that come out of the outstanding questions will be minor, and this works quite well as is. Thanks @sdarnell!

Copy link
Contributor Author

@sdarnell sdarnell commented Jul 26, 2017

Thanks @hwillson. Your suggestions for the characters seem reasonable so long as they're explained in the output. I'd tend to avoid having two filled triangles as it's not immediately clear which is which - maybe it's just me that has triangle-dyslexia? :) But given so many unicode characters to choose from (e.g. arrows there's clearly plenty of options. Maybe even regular characters such as * (asterisk), ^ (hat), † (dagger), ‡ (double dagger), and § (section).

├─┬ babel-compiler@6.19.4                     
│ └─┬ ecmascript-runtime@0.4.1                
│   ├─┬ ecmascript-runtime-client@0.4.3       
│   │ ├── es5-shim@4.6.15[weak] *   
│   │ ├── modules@0.9.2 ^     

Note that as weak dependencies are not displayed by default, it may be simpler to have this explicit?

Anyway, I'm happy with any of the options. Feel free to make the changes, or let me know and I'll do it.

Copy link

@benjamn benjamn commented Jul 26, 2017

I think I prefer the clutter of readable words to potentially ambiguous single characters. Happy to merge this as-is.

@benjamn benjamn merged commit 96db56b into meteor:devel Jul 28, 2017
3 checks passed
3 checks passed
CLA Author has signed the Meteor CLA.
ci/circleci Your tests passed on CircleCI!
continuous-integration/travis-ci/pr The Travis CI build passed
GulajavaMinistudio added a commit to GulajavaMinistudio/meteor that referenced this pull request Jul 29, 2017
Add 'meteor list --tree' to show a tree of package dependencies. (meteor#8936)
abernix added a commit that referenced this pull request Aug 11, 2017
This test doesn't actually run normally, as it's quite slow, but
started failing with the changes to #8936.  This fixes that!
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
Linked issues

Successfully merging this pull request may close these issues.

None yet

3 participants