You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
A concrete case. One of our top level modules referenced in the ref arch depends on a module which then depends on a module.. which in terms depends on https://www.npmjs.com/package/opencollective. That module uses and old version of node-fetch that is reported as having a high vulnerability.
Looking at the module and what it does it's clearly not an issue.
@richardlau did you have any thoughts about how we might have an exclude list when you did the original work on the vulnerability checks?
The text was updated successfully, but these errors were encountered:
I didn't do the original work on the vulnerability checks, that was @aalykiot (I did fix them when the endpoint we were connecting to changed when npm and GitHub merged their databases).
@richardlau thanks for the clarification. I'd looked at who did recent changes and could not quite remember.
I like the suggestion to use https://www.npmjs.com/package/npm-audit-resolver. The collaboration space on that front from the package maintenance team has stalled out. Getting some hands on experience using npm-audit-resolver seems like a good thing on its own as well. The key question I guess is how/what integration with npcheck would look like.
A concrete case. One of our top level modules referenced in the ref arch depends on a module which then depends on a module.. which in terms depends on https://www.npmjs.com/package/opencollective. That module uses and old version of node-fetch that is reported as having a high vulnerability.
Looking at the module and what it does it's clearly not an issue.
@richardlau did you have any thoughts about how we might have an exclude list when you did the original work on the vulnerability checks?
The text was updated successfully, but these errors were encountered: