public api

[naugtur]

Let's discuss what would be useful to expose as public API from npm-audit-resolver

cc @G-Rath

[naugtur]

Expose the result of indexing the dependencies into paths

[G-Rath]

tbh, I don't really see much use in npm-audit-resolver having a public API from the perspective of other auditing tools like audit-app, since they're both operating at the same level - so there's not a lot of sense in having one as a dependency of the other because they both include code to cover the same feature set, so it'd just blowing out the size.

i.e, we're both implementing args parsing, calling different auditors and transforming their results into a normalized output, and then using that output to inform the end developer about the results, mixing in support for adjusting that output based on what ignores are set.

Of that, in my eyes it's the normalizing part that is worth discussing a public api for, as that's the crux of our applications - the rest is pretty straightforward. Ideally this wouldn't be an issue if we had an agreed on public api to serve as a standard for auditors to output, as that'd mean we could skip the normalization step all together.

[naugtur]

audit-resolve.json that npm-audit-resolver produces

[G-Rath]

Ok, but that isn't what I'm talking about - while there's nothing wrong with having that standardized, it's not as useful for the same reasons I said in my original comment: it's npm-audit-resolver specific, so if I wanted the features it provides, I'd just use npm-audit-resolver.

What I'm talking about is the json output from npm audit, yarn audit, and pnpm audit.

[naugtur]

I'm not sure you got what I mean.
We might standardize a file format for storing and sharing decision about what vulnerabilities can be ignored. With possible adoption from snyk and the like.

[G-Rath]

I understand what you mean, and don't get me wrong: I think that's a good thing to do and I'm open to being apart of that - but it's not something that is an actual problem. It makes our tools nicer to work with because they're interoperable, but it doesn't block the ability to audit because users should be able to get good coverage with one of the tools, and worse case can just maintain multiple configs.

What is a large blocker is the current audit output of npm v7, which is missing critical information compared to what v6 provided for us to use, that is expensive for our tools to figure out - it can be done, but it requires a sizable change so the "worst case" is a lot more so than "you maintain multiple files" (and so to me is of higher priority).

The underlying reason for this is because there's no spec around what audit results should provide - this also means that in theory any package manager could put us in this situation e.g. yarn v2 could change some of the information it provides which we'd have to then figure out how to get back if we want to maintain feature parity.

So I think it's premature to be focusing on standardizing a "decisions file" when there's a much bigger problem that'd be better focused on.

(to be clear: I'm happy to be apart of this, and so be pinged on discussions, etc - I'm just wanting to tell you what I think the priority currently should be 🙂)

[naugtur]

Audit is a proprietary nom feature that they were hoping to monetize one day before msft acquisition.
I treat it as free information.

If you want standard input, read package lock and merge it with data from CVE database is the only independent option. I didn't feel like doing that much work 🙈

[naugtur]

Expose decisions (not sure, that's already exposed from core package)