osv-scanner --recursive found nothing in a yarn v4 monorepo - the v4 lockfile format isn't parsed

TL;DR

osv-scanner's yarn parser understands the classic yarn.lock format, not yarn v4's. On a berry monorepo, --recursive walks the tree, parses nothing, and reports zero vulnerabilities with a straight face. Point osv-scanner at the package.json files explicitly so it resolves versions itself, confirm the parsed package count is non-zero, and track upstream parser support for v4 lockfiles.

The query

osv-scanner --recursive found nothing in a yarn v4 monorepo - the v4 lockfile format isn't parsed

Use this when

• osv-scanner --recursive reports zero results on a yarn v4 monorepo
• yarn --version reports 4.x in the repo
• The same command finds results on classic yarn or npm repos

Not for

• Repos that are genuinely vulnerability-free (verify with a second scanner)
• npm, pnpm, or classic yarn lockfiles (those parse fine)
• osv-scanner failing to run at all (an installation problem)

Steps

1. Confirm the yarn version and lockfile shape

yarn --version && head -20 yarn.lock

Expected output: yarn 4.x and a lockfile header that does not look like the classic format. That is the gap.

2. Scan the manifests explicitly

osv-scanner --lockfile=package.json --recursive .

Expected output: osv-scanner resolves the declared dependencies and reports a non-zero parsed package count. The --lockfile flag tells it exactly what to parse instead of guessing.

3. Check the parsed count, not just the result count

Read the scan summary for how many packages were analyzed. Zero analyzed with zero vulnerabilities is the failure mode; hundreds analyzed with zero vulnerabilities is a result.

Expected output: a parsed count that matches the rough size of your dependency tree.

4. Cover every workspace package

Loop over workspace package.json files (packages/*/package.json) and scan each, or confirm --recursive reached them all by comparing parsed counts.

Expected output: every workspace contributes packages to the scan.

5. Watch for v4 lockfile support upstream

Check the osv-scanner release notes for yarn berry support. When it lands, switch back to lockfile scanning, which is more precise than manifest resolution. Verify: the lockfile scan and the manifest scan agree on package counts.

Variant phrasings

osv-scanner yarn berry no results

The ecosystem-name search.

osv-scanner yarn v4 lockfile not supported

The cause-first search.

Compatibility: osv-scanner with yarn v4 (berry) projects. Classic yarn v1 lockfiles are parsed normally.

Why it happens

Lockfile parsers are written per format, and yarn v4 changed the lockfile format substantially from v1. osv-scanner's parser was built for v1. Rather than erroring on an unrecognized format, the recursive walk skips what it cannot parse and reports on whatever it did parse, which in a pure v4 repo is nothing. Silent skipping is the hazard, not the missing parser.

Edge cases / pitfalls

• Manifest-based scanning resolves version ranges to whatever is newest, which can differ from your locked versions. Treat it as an approximation until lockfile parsing lands.
• A repo mixing v1 and v4 lockfiles (migration in progress) gets partial coverage. Scan both explicitly and compare counts.
• Do not "fix" this by downgrading to yarn v1. The lockfile format is not worth a toolchain regression.
• Zero findings on any new scanner setup deserves a second opinion. Run one more scanner before declaring the repo clean.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_EDtMjfKn-xEBN1p1yTdGUQ