Add --subdep-warn-only option

[jcare44]

We are using nsp as a build checker (with https://github.com/FGRibreau/check-build) and it's great to see the vulnerabilities found in sub-dependencies, but we can't always afford to fix them.

[latentflip]

Not sure how it interacts with check-build exactly, but you can add exceptions for vulnerabilities as per: https://github.com/nodesecurity/nsp#exceptions as an alternative too.

[jcare44]

Yes, but exceptions are less handy in our use case. We have a lot of repositories, so managing exceptions locally would really be a pain. We could manage it globally, but it would hide some security issues that we don't want to hide.

For example, in our APIs, we usually use Hapi and swaggerize-hapi. Hapi is vulnerable in versions <11, and swaggerize-Hapi embed Hapi v8. If we disable https://nodesecurity.io/advisories/45 globally, it would not report the old projects where we are still on older versions of hapi.

That's why disabling sub dependencies break is really the solution for us.

[FGRibreau]

Well said @jcare44, indeed @latentflip we've put a lot of thought into this, adding an exception is not a solution as it will quickly be a real pain to manage both locally or globally.

--subdep-warn-only will allow us (in our build process) to be alerted about direct dependencies we can act on and be notified about indirect-dependencies security issues.

[latentflip]

Fair enough, just pointing out an alternative :)

Will let @nlf / @evilpacket chime in on this PR, but seems reasonable to me.

[evilpacket]

I think we should be doing this server side instead of client side personally to reduce the load put into the check function for extremely deep package or shrinkwrap trees. @nlf thoughts?

[nlf]

If it's a warn only on subdeps, then I agree with this pull request. If it's an ignore subdeps altogether, it needs to be server side. Or I suppose the client can send a generated shrinkwrap that contains only the top level dependencies...

[evilpacket]

@nlf oh right makes sense. If we want to warn and still show that info. fine with me.

[evilpacket]

This pr is good but just a side note so I don't forget while I was looking more at this.

This works fine when only package.json is in use. As soon as shrinkwrap files with npm3 are in use then it doesn't work quite right. This is not due to this pull request but due to how we are parsing things and behavior of npm 3. I'd like to wait on this until we get that other situation figured out and do those both at the same time.

[nlf]

will update this and recreate