← back to npm Provenance Check
npm audit signatures?The npm CLI already has a command that reports provenance:
npm audit signatures
It's real, it's accurate, and if all you want is a one-time answer for the project in front of you, it's the right tool -- this page isn't arguing against it. What it doesn't do is what this tool exists for.
1. It needs a full install of the project. npm audit signatures reads your local node_modules and package-lock.json, which means npm install has already run. This tool works from a pasted lockfile, package.json, or even a plain list of names -- useful when you're evaluating a dependency before adding it, reviewing someone else's lockfile they sent you, or checking a repo you haven't cloned.
2. It's one project at a time, with no report to hand off. If you maintain (or audit) more than one repository, there's no built-in way to see "which of these 40 repos still has unmigrated dependencies" without running the command in each one and copying results by hand. This tool's CLI emits --json, so a script can loop over repos and diff the output.
3. No bulk or CI-shaped output. npm audit signatures is built for a human reading a terminal, not for a machine reading a report. The CLI here has a flag built for exactly that:
node cli.mjs package-lock.json --without-provenance-only --json
which returns just the packages still missing an attestation, as JSON, ready to file into a spreadsheet, a Slack digest, or a migration tracker.
There is no separate provenance database. Both npm audit signatures and this tool read the same registry field -- dist.attestations.provenance on a published version -- so they will never disagree about a given package's status. The difference is entirely in what you can start from and what you get out, not in what's being measured.
Yes -- npm audit signatures reports the same registry provenance field this tool does. What it does not do is work from a lockfile before you have installed the project, produce a report across more than one repository, or emit JSON another tool can consume. Those three gaps are what this tool adds.
No. Both read the exact same registry field, dist.attestations.provenance, on the exact same published version. There is no separate provenance database for either tool to disagree about.
When you already have the project installed locally and only need a one-time answer for that one project -- it needs no separate tool and no network request beyond what npm already made during install.