search

alanshaw / david-www

:eyeglasses: David helps keep your Node.js project dependencies up to date.
https://david-dm.org
MIT License
729 stars 131 forks source link

Project health visualisation #36

Open alanshaw opened 11 years ago

alanshaw commented 11 years ago

This is kind of a placeholder for ideas and improvements that can be made to david to better visualise project health.

alanshaw commented 11 years ago

Some way of knowing what went into a project dependency to transition it from the previous versions to the next.

Parse changelog? - inconsistent and oft unfollowed standard Commit history since last version change?

olizilla commented 11 years ago

In your talk at LNUG, there was an interesting point about how some projects have dangerously i'll-defined dependencies, like "foo": "*" for all the things, where you get the absolute latest version available regardless of minor or major breaking changes... or, the 'death-star pattern'. No matter how big you build it, at some point the rebel alliance of other developers are gonna come and blow you up with an unexpected change. http://youtu.be/DOFgFAcGHQc?t=3m22s

Given that I have no control over when dependancies get updated, over time, all my old projects will end up with red badges, as the projects I depend on move on. If I've declared my dependencies sensibly, like: "foo": "2.4~", allowing for security and patch updates on a 2.4 version, but no major or minor functional changes, then it doesn't much matter that I haven't kept up. My dependencies are still "good", or at least, there is a chance my project will still work in a years time, which is more than can be said for the death-star version.

Where I'm going with this is that it might be good to provide badges that say: "Yep, this module has sane dependencies". That would be super useful when judging a large dependency tree, as even if you vet the modules you directly depend on, there could still be a death-star module deep in the tree as a sub-sub dependency.

...With David watching, the tree view could show modules with unsafe dependency definitions at any point in the tree.

alanshaw commented 11 years ago

With safe dependencies being defined as a finite range or pinned I guess. Unsafe being (for example):

*
latest
>= 0.1.0
ilanbiala commented 9 years ago

This would be nice to have.

gabrielcsapo commented 8 years ago

👍