Closed silamon closed 1 year ago
I think it'd be good if we could indicate the Lockfile as source in the header of the results page. Something like
This project contains 24 outdated main dependencies, based on the
Cargo.lock
file present in the repository.
I agree it's good to indicate, but I don't think that's the right place to mention it. There should be some kind of metadata section where this can be better displayed, I think. For now, I've added it on the place you've suggested.
What's some good test cases to try?
Would we at the current time expect them to show different things?
cargo outdated -R
seems to think so?
I agree it's good to indicate, but I don't think that's the right place to mention it. There should be some kind of metadata section where this can be better displayed, I think. For now, I've added it on the place you've suggested.
You're right, by now a "metadata" section may also make sense. But I think that the fact that this report is based on the lockfile is crucial and should be shown in plain sight. Otherwise, devs may become confused as to why their project shows as out of date even if their Cargo.toml
is sufficiently permissive.
@robjtede Do you mean the different data for latest
? I noticed that too, but had the same issue in my checkout from the main branch, so I thought it was a local problem on my end.
I mean that this MR should cause deps.rs to show 9 outdated deps, according to the lockfile, same as what is reported by cargo outdated
, but at the moment it shows that everything is up to date? Unless I'm missing something fundamental.
You should check the example in the original issue. That's a perfect example.
Please note: I just saw a few issues in the deps.rs repository and deno repository. For deno, pinned crates are no longer respected. For deps.rs the result should remain the same, but the base64 crate is incorrectly up-to-date. I might need to fix those before merge.
If the Cargo.lock is available in the repository, let's use it. Related to #26.