Ignore all vulnerabilities from dependencies installed by given package

[archfz]

Using the option -m can only ignore vulnerabilities in a specific package. It would be nice if we could ignore a whole package and it's child dependencies (packages installed by it). I believe this could be included in the same -m option.

So for example if I have node-sass installed, and it brings node-forge and trim-newlines with security vulnerabilities, -m node-sass would ignore both. But on the other hand if I also have package-x that also installs node-forge then it doesn't.

Context: in certain cases the split between production and non dev only packages is used for other purposes. Like for example installing less packages in certain pipelines (frontend web targeted only projects do this). So using only --production doesn't cover this case.

[rulrok]

I just run into this situation myself.

There is one package that I know it is safe to ignore. And only it has many vulnerable dependencies which ends up generating quite some noise on the final report.

My suggestion is that it could be a new feature, instead of using the already existing -m flag, maybe a new one.

--tree-ignore | -t 👀

[jeemok]

as we all know the different versions in npm has big discrepancies by the information provided in the report, hence this feature might be difficult to handle properly for e.g. npm v6 and v7;

in v6, we might be able to analyze the dependencies tree using the path field: https://github.com/jeemok/better-npm-audit/blob/master/test/mocks/v6-json-buffer.json#L813

however, in v7+, it seems like there is only e.g. nodes field that reflects the physical package location instead of dependencies tree: https://github.com/jeemok/better-npm-audit/blob/master/test/mocks/v7-json-buffer.json#L21

we might need to find an alternative solution to list and analyze the dependencies tree (perhaps npm ls) for each found vulnerability, which might be costly.

there is a related discussion (https://github.com/jeemok/better-npm-audit/discussions/53) of where we tried to read into the installed package's nsprc file and to ignore its child dependencies. However, we've got some blockers, and wasn't able to roll it out successfully