The lockfile created by npm 5 puts the current version of dependencies into the requires set, rather than the intended dependency range. As a result, packages seem like they're vulnerable because they appear to be pinned to a vulnerable dep. However, when we get the packuments in the audit process, we see that they're not actually vulnerable, so it looks like npm audit fix will fix the problem. But then, when we run npm audit fix, we get an idealTree out of the package-lock.json that has the deps pinned again!
One solution might be to have audit correct the idealTree and refresh the lockfile metadata, so that the subsequent reify() call for audit({fix:true}) has the updated dependency ranges.
The lockfile created by npm 5 puts the current version of dependencies into the
requiresset, rather than the intended dependency range. As a result, packages seem like they're vulnerable because they appear to be pinned to a vulnerable dep. However, when we get the packuments in the audit process, we see that they're not actually vulnerable, so it looks likenpm audit fixwill fix the problem. But then, when we runnpm audit fix, we get anidealTreeout of the package-lock.json that has the deps pinned again!One solution might be to have
auditcorrect theidealTreeand refresh the lockfile metadata, so that the subsequent reify() call foraudit({fix:true})has the updated dependency ranges.