Feature request: Display transitive dependency versions
Opened this issue · 9 comments
Currently (v0.2.3.0) only the versions of immediate dependencies are listed.
Would you be able to explain why you would find this useful? Intuitively this makes sense to me, but I'm struggling to come up with a concrete reason.
It makes sense to me that seeing a transitive dep has the same utility as seeing an immediate one.
- The library depends on both.
- Libraries tend to treat them the same; that is, if you depend on a library then you also have use of the things it depends on.
- If you already depend on a different version of one of the deps you will have to do some dependency resolution, regardless of whether or not it is a transitive dep.
I believe it was @paf31 who recently asserted that using a value from a transitive dependency without explicitly declaring it as your dependency is okay. The reasoning was that a change in a transitive dependency is considered a breaking change in languages with a module system like ours. Because of that, this information is valuable.
This will need to take in to account the conflict resolution block in bower.json (can't remember the attribute name).
I haven't looked into it at all but I assume bower can give us all the info we need for this?
Ok, makes sense.
Currently, we have the version ranges for immediate dependencies stored in the Pursuit database, via the bower.json file.
I suppose we would have to use the specified version ranges for declared dependencies to build up a Map PackageName VersionRange; if a particular package is listed as a dependency more than once, (that is, if A depends on B and C, both of which depend on D), then I guess we would need to find the intersection of the ranges specified by B and C. Also we would need to address #100 first.
I think we would probably need to use the Bower registry as well, because we can't currently assume that dependencies are already in the Pursuit database. In fact, I wonder if it would be possible to just use Bower here, as this sounds like it's just the first half of resolving Bower dependencies (the second half is choosing specific versions).
I'm not so sure about the "resolutions" field, though. It is a specific request to ignore or override dependencies of other packages, right? Certainly useful in some contexts, but I don't think that packages that are on Pursuit should use them.
About the resolutions field: are you saying Pursuit should reject packages with a resolutions block or just ignore it? I don't know how often this is actually used, but I thought it was relevant so I mentioned it.
I'm not really sure. I don't want Pursuit to give the impression that resolutions blocks are a good idea; building in explicit support for them seems to do so. Perhaps we should reject packages that have them, I'm not sure. I think ignoring them with respect to this feature would probably be ok.
👎 for any resolutions.
Sorry, could you expand a bit? I'm not sure what you mean.