Why is a certain indirect dependency being installed?

I’m on Meteor 1.3-rc.2, and for some reason cosmos:browserify 1) is being installed and 2) isn’t being updated. How do I figure out what is depending on this?

Earlier today I had cosmos:browserify stuck on version 0.9.x (can’t remember if x was 3 or 4) and it wouldn’t upgrade to 0.10.0. On a whim I rm’d .meteor/versions, and now it is stuck on 0.8.4 after a fresh meteor update.

I checked its Atmosphere listing, and none of the dependents appear in my .meteor/versions. I thought it might have been to kadira:flow-router since meteorhacks:flow-router is a dependent and was kadira:flow-router’s predecessor, but removing flow-router doesn’t remove browserify.

I guess it isn’t a huge deal, but it’s a bit frustrating when analyzing my dependency graph that I can’t figure out why a specific package is being installed. At the very least meteor remove cosmos:browserify could say something like Cannot remove: foo:bar depends on cosmos:browserify >= 0.9.0 or something similar, just like apt-get and other package managers do. Is there any way to get this information?

Thanks.

2 Likes

OK, figured this out after removing packages one by one. Turns out I am in fact depending on a package that uses cosmos:browserify. I’m also a blind screen reader user, and Atmosphere doesn’t appear to have any non-visual indicator or mechanism for scrolling the list of dependents if there are more than 10. Had I known there were more than 10 for cosmos:browserify, I could have scrolled through them and found what I needed.

Still though, it’d be nice if meteor remove explained why it couldn’t take a given action. I’ll likely file that as an issue.

1 Like