Adds --parseable parameter to audit

[luislobo]

How and why the current situation is problematic: npm is too verbose for purposes like doing a `| grep critical' and having real useful information for automated tools

By adding a new --list parameter this situation can be handled, being also an optional one. For a detailed list of changes/updates needed, there still always is the default audit command.

Use cases: when automating security audits, the result can easily be parsed by any tool.

Any caveats: Needs npm/npm-audit-report#10. There is a TODO comment in that PR that needs to be answered/addressed.

[luislobo]

@zkat Could you help me here? I don't know where you define the extra params so that the unit test passes...

[legodude17]

If I understand this right, you need to put some documentation about it here, base it off of another file in that directory. Also here add it to defaults and types.

[zkat]

@luislobo so since this is meant to be greppable, what about using --parseable?

Try npm install --parseable -- I wonder if this is more what you'd like, instead of making something that looks like a human-readable view blow right past 80col?

[luislobo]

@zkat I just checked --parseable, I like the idea. I could actually add both, --list and --parseable, as I can see the use of both. The current one as a "simple" view of the default one, and the parseable one only for tooling/automation. What do you think?

[luislobo]

I was also thinking of making --list columns configurable, so you can add/remove columns, but that was kind of a stretch goal after the basic implementation is done

[luislobo]

@zkat @evilpacket I've just updated both npm/npm-audit-report#10 and here to match what you have suggested. I hope this lines up with what might be a good solution for everyone out there.

[luislobo]

Current output looks like these, of course it goes out of the bounds of 80 chars, but as a parseable solution, it's acceptable. I've been able to grep it, awk it and it's great so far

[luislobo]

Finally, one thing that I did, is group by severity, so that the output is sorted by High, Moderate, and Low

[iarna]

While we're adding --parseable we should add --json as well. There's already a npm-audit-report JSON reporter so adding it should be very little work.

To land this will need to have passing tests. The failure on Node 6 can be fixed be rebasing on to the current version of the branch. The other issues seem to be formatting issues that are making our linter unhappy.

[legodude17]

@iarna --json was already added to npm audit by #20568.

[luislobo]

@legodude17 One thing I noticed about #20568. is that it doesn't add Docs or help. I'll add it in this branch if you all are OK.

[legodude17]

@luislobo Not my call to make

[luislobo]

@iarna I fixed the standard issues. Should be good to go, AFAIK.

[luislobo]

This param needs npm/npm-audit-report#21

[luislobo]

@zkat Any chance this can be added to next releases? We are using it internally and really saves time checking all our modules (have more than 40) but we have to keep updating whenever there's a new npm version.

Thanks!

[luislobo]

@zkat @iarna I don't want to be pushy, may be I just need to follow some process that I'm not aware of, but, how does a PR get into the list of PRs to be evaluated as one that might get into a release?

[luislobo]

@zkat any chance to get this one reviewed?

[zkat]

I got around to merging all the PRs on npm-audit-report, so this should be unblocked. /cc @iarna

[luislobo]

Thanks @zkat. @iarna let me know if there are any changes needed here

[zkat]

we're good, I think! Thank you!