Conversation
ec43f8c to
6c3b372
Compare
|
After fixing the issue in our @willdurand Before considering adding these two to our nsprc and file bugs to remove the exceptions, I think that we may want to consider merging the dependabot PRs that are hitting only the audit-deps failure and then double-check how many other dependency are still make us hit the npm audit-deps because of this two advisories (and if any of them is actually part of runtime dependency which would also be hit by users of the web-ext package). wdyt? |
+1 |
While reviewing the CI jobs failure hit by most of the dependabot PR opened over the last week we noticed that it was hitting the
audit-depsstep of the CI job but the output of ouraudit-depsnpm script (which parses the json output of thenpm auditcommand) wasn't always providing the details about the security advisory associated to the reported npm dependency, e.g. like here for nyc: https://app.circleci.com/pipelines/github/mozilla/web-ext/2388/workflows/f22e2ff0-ed9c-4373-88d5-bccb0bf6869c/jobs/9630?invite=true#step-116-141Looked into the reasons behind that, I noticed that the
audit-depsscript was currently assuming that the via attribute in each of the reported npm packages details was going to be either an object with the details for the security advisory or a string that is meant to be the package name from which that package is inheriting the security advisory, but it wasn't accounting for more deeply nested casesThis PR does apply a small change to recursively resolve the elements of the
viaproperties, which as an example turns the output from the linked PR:into the one we expected: