Process on resolving pnpm audit findings

[simhnna]

We're currently using npm pretty much everywhere at my company. I'm exploring pnpm as an alternative.

I'm not sure what the equivalent of npm audit fix is in pnpm. Coming from npm I'm used to being able to update what's needed to remove known security issues. AFAIK there's no single command that accomplishes the same in pnpm.

The closest I got was to

1. pnpm audit --fix to populate overrides,
2. pnpm install to persist changes in lockfile,
3. remove overrides
4. pnpm install
   That way the dependencies that were overridden stay there as long as they comply with all specified version ranges. Remaining audits need to be looked at again

How do others handle that? Just live with the overrides?

[ronjouch]

Agreed. To reformulate OP and try to understand the pnpm status quo: is there a rationale for pnpm audit --fix to only add overrides and to not touch pnpm-lock.yaml (as someone familiar with npm audit fix would expect)?

In the case where I want to fix security issues, what I expect as a package manager user is to update the source of truth defining the tree of packages to use... a.k.a. the lockfile. And so,

1. I want to keep my package.json & pnpm-workspace.yaml untouched! (Since my semver requirements didn’t change)
2. I want to update pnpm-lock.yaml so that patched versions are used (Since it’s the prod source of truth)
3. Finally, to someone who would say “then just nuke & recreate the lockfile”, no I don’t want to wholly “regenerate” the lockfile (this is a separate concern, with more risks), I just want pnpm to selectively update the vulnerable packages in the lockfile.

Am I/we missing something? Is there a benefit to the current behavior of pnpm audit --fix ? Would a new flag pnpm audit --fix-in-lockfile make sense?

[zkochan]

In my experience the fixes to the vulnerabilities are frequently only released for the last major version. As a result, pnpm update -r <vulnerable-dependency-name> doesn't always update all the vulnerable versions.

Usually I do run update first and when that is not enough, I run pnpm audit --fix and pnpm install.

then just nuke & recreate the lockfile

That's not needed, if pnpm update doesn't help, nuking won't help either.

I did not have any knowledge about how npm audit fix worked. We have implemented our solution from scratch independently. If someone wants to improve how this works, I don't have objections. For me it isn't high priority at the moment. I'd rather just improve the docs if that helps.

[ronjouch]

@zkochan thx for listening 🙂

fixes to vulnerabilities are frequently only released for the last major version. As a result, pnpm update -r <vulnerable-dependency-name> doesn't always update all the vulnerable versions.

Agreed. Tangentially, from the perspective of someone used to npm audit fix, my immediate answer to this is: why would I bear the burden to repeatedly (if multiple vulns to patch) individually update vulnerable dependencies by calling pnpm update -r <vulnerable-dep>name> ? I’d like to be able to pnpm audit fix just like I npm audit fix, and the tool (not me!) does the job of performing the minimal set of lockfile security updates, for one or several deps 🙂.

Usually I do run update first and when that is not enough, I run pnpm audit --fix and pnpm install

Okay this confirms what OP says. For now, pnpm audit --fix && pnpm install && git restore pnpm-workspace.yaml kinda is equivalent to npm audit fix in updating the lockfile only (with obvious git caveats).

I did not have any knowledge about how npm audit fix worked. We have implemented our solution from scratch independently. If someone wants to improve how this works, I don't have objections. For me it isn't high priority at the moment. I'd rather just improve the docs if that helps.

👍. A precision requet to you for a future-me-with-enough-time-to-work-on-this, or any motivated passerby: what would be the CLI API you’d expect, given A. existence of pnpm audit --fix and B. existence of npm audit fix ?

• A. In the absence of pnpm audit --fix I would have pushed for pnpm audit fix, but then we’ll have both pnpm audit fix and pnpm audit --fix, very weird IMO
• B. Sooooo... pnpm audit --fix-in-lockfile ?
• C. Or maybe pnpm audit --fix --lockfile-only ?
• D. Something else?

Given the rest of the pnpm CLI API, would you go for B. / C. / D. ? Thanks for pnpm!