Improve output display.

[davidlehn]

External comments related to the display:

• Sort by CVSS score so most important things are at the top.
• npm audit output seems duplicative of OSV table? Don't make devs read the same information twice, put everything in one table if possible.
• npm list output doesn't seem useful, can't a developer just do that themselves when they go in to try to fix what's wrong? Again, information overload, unless it's vital to put that info in the PR, leave it out.

[davidlehn]

• Sort by CVSS score so most important things are at the top.

The output is markdown and basically limited to static display. It would be nice to have a sortable table, but that's probably not possible.

While I understand the reason for wanting to see the more important issues, I'm not sure this is a big issue in practice. When I've looked at the output, I go in and try to fix it all. And there are usually only a few items, so not hard to scan the list. For projects that have let issues accumulate, they really need to address it all too.

I think the sorting by package name is usually fine. And it does help to see all bugs for one package name clustered. Though sometimes that can be for multiple versions in multiple dependency paths.

• npm audit output seems duplicative of OSV table? Don't make devs read the same information twice, put everything in one table if possible.

It's two tools using, maybe, different databases of issues. This was initially added when there definitely was a difference in the two lists. I was seeing clean OSV output but npm audit showed issues, or vice versa.

Combining the lists seems challenging. From some inspection, it's not obvious how to de-duplicate issues. The ids are from different systems, though might be the same issue. I think in practice developers will fix one or more issues, rerun scans (via cli or let a PR do it) and issues will get pared down to nothing or an issue in one system or the other.

• npm list output doesn't seem useful, can't a developer just do that themselves when they go in to try to fix what's wrong? Again, information overload, unless it's vital to put that info in the PR, leave it out.

I think that feature came about because of a flow I was doing. I'd need to run the npm list manually, then have to cross reference with the packages in the reports, and scan through the entire list output to find the dep paths of interest, then go up the tree to find what root packages needed updating. This is helping to automate that. When there are lots of issues, it's a very long list! Which is why a recent change collapsed that output. But for a few issues, it's quite reasonable to look at.