@askdesigners Yup, that's exactly what this post is about. Just like in this post, I was using jest@23.x.x and it had 62 vulnerabilities coming from multiple internal packages that jest uses.
When running the suggested command that came from NPM, run npm install --save-dev jest@24.8.0, it will then grab that specific version of jest that fixes the vulnerabilities. This means that the maintaner(s) of your package have fixed the vulnerabilities and pushed a new version of their package for you to use.
Another option, that I wouldn't recommend, is to install the vulnerabilities of the internal packages into your own project. For example, if one of your packages is reporting a vulnerability from an internal package, braces like in my example in the post, you could install the fixed version of that package yourself using npm i --save-dev braces but this could cause breaking changes.
Hi Brandon, thanks for your post. I'm trying to fix the same vulnerability in your example, braces, which I have as a four-level-deep dependency, without any success. npm audit reports it as having the path cpx > chokidar > anymatch > micromatch > braces and I've specifically installed the latest version of all of those packages:
Even so, npm audit continues to report the vulnerability. I've deleted node_modules and package-lock.json and run npm install again, but it still doesn't resolve the issue. Is there something else that I need to do? I'm pretty much at my wits' end at this point.
Typically, I found a workaround after writing the above. It turns out that cpx is unmaintained. There's a fork called cpx2 that works as a drop-in replacement and resolves the vulnerability. Would the solution to this problem otherwise have been to get cpx to update its dependencies, though?
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
@askdesigners Yup, that's exactly what this post is about. Just like in this post, I was using
jest@23.x.xand it had 62 vulnerabilities coming from multiple internal packages thatjestuses.When running the suggested command that came from NPM,
run npm install --save-dev jest@24.8.0, it will then grab that specific version ofjestthat fixes the vulnerabilities. This means that the maintaner(s) of your package have fixed the vulnerabilities and pushed a new version of their package for you to use.Another option, that I wouldn't recommend, is to install the vulnerabilities of the internal packages into your own project. For example, if one of your packages is reporting a vulnerability from an internal package,
braceslike in my example in the post, you could install the fixed version of that package yourself usingnpm i --save-dev bracesbut this could cause breaking changes.Hi Brandon, thanks for your post. I'm trying to fix the same vulnerability in your example,
braces, which I have as a four-level-deep dependency, without any success.npm auditreports it as having the pathcpx > chokidar > anymatch > micromatch > bracesand I've specifically installed the latest version of all of those packages:Even so,
npm auditcontinues to report the vulnerability. I've deletednode_modulesandpackage-lock.jsonand runnpm installagain, but it still doesn't resolve the issue. Is there something else that I need to do? I'm pretty much at my wits' end at this point.Typically, I found a workaround after writing the above. It turns out that cpx is unmaintained. There's a fork called
cpx2that works as a drop-in replacement and resolves the vulnerability. Would the solution to this problem otherwise have been to getcpxto update its dependencies, though?