-
-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Bug?]: yarn npm audit --recursive produces incomplete output (yarn 4) #5781
Comments
I'm afraid that more a bug report for the npm registry. The "modern" npm audit endpoint sends fewer data than the "legacy" one (but it's more stable, whereas the legacy one requires to send a full dependency tree that doesn't work well w/ Yarn). |
As an example, this is everything we get in response:
|
@arcanis thanks for the quick reply! Just for my own understanding, is this discrepancy something that yarn plans to deal with internally or do you suggest developers implement userland tooling to deal with it (at least for the time being)? We've quickly put together something that could help us cope with this issue for the time being, but thought it would be worth getting some feedback from upstream before committing to such a hacky solution! 🙈 audit.js
|
I think the best we could do would be to change this line to be
(You can run |
I think for external tool integrations it would be great to always have the same expected structure returned, but I'm in no position to assess who's responsibility it is to "fix that" :) In our usage case, we are using audit-ci together with yarn3 and the new output breaks the integration with some nasty side effects as it returns yarn3
yarn4 (with proposed change)
|
We are switching to yarn4 and ditching audit-ci. I think we can close this ticket though since the output is the expected one, it's just radically different from what yarn3 produces, which might make the migration path harder for some people. For those who might be interested: #!/usr/bin/env node
const util = require('util')
const exec = require('child_process').exec
cmd = 'yarn npm audit --json --recursive --no-deprecations'
console.log(`Execing: ${cmd}`)
exec(cmd, { timeout: 15000 }, function (err, stdout, stderr) {
let vulnerabilities = {}
let found = 0
let parsed
const useColors = (process.env.NO_COLOR || "0") === "0"
const addVulnerability = (key, data) => {
vulnerabilities[key] = data
}
console.log(`Exit code: ${err != null ? err.code : 0}`)
try {
parsed = JSON.parse(stdout)
} catch (e) {
console.log(`Error parsing returned json from command: ${e}`)
console.log(stdout)
process.exit(1)
}
if (err !== null) {
for (const [name, data] of Object.entries(parsed)) {
if (typeof data[0] === 'undefined' || typeof data[0].id === 'undefined') {
console.log('debug: ignored invalid entry (possibly a deprecation)')
continue
}
addVulnerability(name, data[0])
}
}
found = Object.keys(vulnerabilities).length
if (found !== 0) {
console.log('\nyarn npm audit report')
console.log('---------------------------')
console.log(util.inspect(vulnerabilities, {showHidden: false, depth: null, colors: useColors}))
}
if (found === 0) {
console.log('\nHooray! No vulnerabilities found!')
} else {
console.log(`\nUh-oh! Found ${found} vulnerabilities, check the output above for details.`)
}
process.exit(found === 0 ? 0 : 2)
}) |
Note that there's a bug in the output which I fixed in #5833. The format will be slightly different in 4.0.1 (will release in a couple of hours). Can you double-check it works well enough for you? You can use this command line to try the master build:
|
That sadly breaks because I'm expecting valid json and now nothing is returned if no vulnerabilities are found. |
The |
I see, that makes sense. Thanks. No worries, I'll adapt my script accordingly. |
With yarn 4.0.1, I'm able to narrow down my wrapper to an inline script:
EDIT: or just use |
Self-service
Describe the bug
I have a an application with a dependency tree that causes issues with
yarn npm audit --recursive
.For yarn 3.x it errors out with a "bad request" error which I managed to narrow down to #4117 and, following the thread's advice, switched to yarn4 (rc53 at the time of writing).
With yarn 4.x I no longer receive the "bad request" error but receive incomplete output, the json structure is totally different than what would be expected (no summary is displayed, the advisory information is incomplete, etc):
The incomplete output returned by yarn4
An example of the expected output for yarn3
To reproduce
dependencies (
yarn info --json --name-only -A | jq -r .
):Environment
Additional context
No response
The text was updated successfully, but these errors were encountered: