npm audit versus yarn audit - node.js

Question

I have a React Native project (0.61.4) that uses yarn as its package manager.
When I run yarn audit a huge number of vulnerabilities are reported:
18202 vulnerabilities found - Packages audited: 958823
Severity: 18202 High
✨ Done in 14.34s.
Most are in some very deep dependency paths. For instance:
┌───────────────┬──────────────────────────────────────────────────────────────┐
│ high │ Prototype Pollution │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Package │ lodash │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Patched in │ >=4.17.12 │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Dependency of │ react-native │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Path │ react-native > #react-native-community/cli > │
│ │ metro-react-native-babel-transformer > #babel/core > lodash │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ More info │ https://www.npmjs.com/advisories/1065 │
└───────────────┴──────────────────────────────────────────────────────────────┘
When I run npm audit, it first reports:
Neither npm-shrinkwrap.json nor package-lock.json found: Cannot audit a project without a lockfile
So I run:
npm i --package-lock-only
A package-lock.json file is generated. On inspection this file seems correct.
When I now run npm audit, the results are:
=== npm audit security report ===
found 0 vulnerabilities
I don't understand the discrepancy between these two package managers. Why does npm report 0 errors, and yarn 18.202?

Answer 1

It's very hard to estimate why is this happening without looking at both the lock files and comparing. But, as far as I can tell, it can happen only if both the lock files are resolving to different versions of same dependencies.
Your yarn.lock file was generated earlier, thus it contains vulnerable and old versions of dependencies and since the package-lock.json was generated afterwards, it would have resolved to latest/fixed versions of those dependencies.
Remember that npm i --package-lock-only would just create the package-lock.json file, not install anything, but it won't be at-par with the actual installed packages. I think you assumed that running that command would just derive the lock file from installed packages, but it actually generates the lock file as if you ran it without the flag.
So in conclusion, both the lock files are resolving to different (minor/patch)versions of same dependencies.

Answer 2

This is not an apples-to-apples comparison between Yarn and Npm. It's true that they don't report the exact same audit warnings, but you could get the same/similar result from Yarn if you did the following:
rm ./yarn.lock
yarn
yarn audit
Why is that? Because Yarn was working with knowledge from your previous dependency management work, while Npm started from scratch, having never been run before in your project. If you remove yarn.lock, Yarn will start from scratch as well. Either way, you will get the latest patch level versions of all your libraries, which you wouldn't have otherwise. This will cause many of your audit warnings to go away.
So what are yarn.lock and package-lock.json? After each successful install run, Yarn saves the latest state of your node_modules (your dependency tree) in yarn.lock. NPM does the same in package-lock.json. These two auto-generated files are like detailed versions of your package.json, listing every dependency und sub-dependency you have installed (with version numbers down to the x.x.x patch level) – and why they were installed. That way, your node_modules will look exactly the same on each run of yarn install or npm install.
However, these 2 lock files are exclusively used by the respective package manager and not compatible: Yarn and Npm would likely keep changing your node_modules if you use them in an alternating fashion. This will cause lots of subtle bugs. That's why you generally should stick with using either Yarn or Npm in one project.