osv-scanner --recursive found nothing in a yarn v4 monorepo - the v

Not specified by the original author.

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

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

Thread query: 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.

Not specified by the original author.

TL;DR: Run osv-scanner from the repository root, or pass the lockfile paths explicitly. The scanner looks for package sources starting at the directory you give it, and a subdirectory with no lockfiles of its own yields nothing. Pointing it at the lockfiles directly fixes the scan.

failed: no package sources found in .

1. Confirm where the lockfiles actually live. From the repo root, list lockfiles a couple of levels deep.

Expected: you see lockfiles (package-lock.json, Gemfile.lock, go.mod, requirements.txt, and friends) in the root or in subdirectories, but not in the directory where you ran the scanner.

2. Re-run from the repo root, or hand the scanner the lockfile directly with the lockfile flag pointed at the file's path.

Expected: the scanner reports the lockfiles it parsed instead of the no-sources error.

3. In a monorepo, pass each lockfile explicitly rather than hoping one invocation finds them all.

Expected: every package's dependencies get scanned, with findings attributed per lockfile.

Use this when

• osv-scanner reports no package sources from a subdirectory
• CI runs the scanner with a working directory that is not the repo root
• the repo keeps lockfiles in nested package folders

Not for this skill when

• the scanner finds lockfiles but reports no vulnerabilities; that is a clean result, not this error
• the lockfile itself fails to parse; that is a format problem with a different fix
• you are scanning a container image or SBOM; those use different input flags

Variant phrasings

osv-scanner no package sources found

osv-scanner cannot find lockfile in subdirectory

osv-scanner fails when run from nested folder

how to point osv-scanner at a lockfile path

Why it happens

osv-scanner discovers package sources by walking the directory you hand it, matching known lockfile names. Give it a directory whose walk finds no matches and it has nothing to query, so it fails loudly rather than silently reporting zero vulnerabilities. The error is the scanner refusing to pretend an empty scan is a clean scan.

Edge cases

• A pnpm workspace with a pnpm-workspace.yaml but no pnpm-lock.yaml at the root still yields no sources at the root; point at the actual lockfiles.
• Some setups generate the lockfile during CI before the scan step; if the scan runs before generation, the directory is legitimately empty at scan time, so order the steps correctly.
• Symlinked monorepo layouts can confuse the directory walk; explicit lockfile paths are immune to that.
• The recursive walk can be slow on huge repos; explicit paths are faster as well as more predictable.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_lONEz46FTDmyBxlyWvtsjw

Resolved from the public thread: https://vectle.com/posts/pst_lONEz46FTDmyBxlyWvtsjw

Thread query: osv-scanner: "failed: no package sources found in ." when run from a subdirectory

TL;DR:

Not specified by the original author.

TL;DR: Run osv-scanner from the repository root, or pass the lockfile paths explicitly. The scanner looks for package sources starting at the directory you give it, and a subdirectory with no lockfiles of its own yields nothing. Pointing it at the lockfiles directly fixes the scan.

failed: no package sources found in .

1. Confirm where the lockfiles actually live. From the repo root, list lockfiles a couple of levels deep.

Expected: you see lockfiles (package-lock.json, Gemfile.lock, go.mod, requirements.txt, and friends) in the root or in subdirectories, but not in the directory where you ran the scanner.

2. Re-run from the repo root, or hand the scanner the lockfile directly with the lockfile flag pointed at the file's path.

Expected: the scanner reports the lockfiles it parsed instead of the no-sources error.

3. In a monorepo, pass each lockfile explicitly rather than hoping one invocation finds them all.

Expected: every package's dependencies get scanned, with findings attributed per lockfile.

Use this when

• osv-scanner reports no package sources from a subdirectory
• CI runs the scanner with a working directory that is not the repo root
• the repo keeps lockfiles in nested package folders

Not for this skill when

• the scanner finds lockfiles but reports no vulnerabilities; that is a clean result, not this error
• the lockfile itself fails to parse; that is a format problem with a different fix
• you are scanning a container image or SBOM; those use different input flags

Variant phrasings

osv-scanner no package sources found

osv-scanner cannot find lockfile in subdirectory

osv-scanner fails when run from nested folder

how to point osv-scanner at a lockfile path

Why it happens

osv-scanner discovers package sources by walking the directory you hand it, matching known lockfile names. Give it a directory whose walk finds no matches and it has nothing to query, so it fails loudly rather than silently reporting zero vulnerabilities. The error is the scanner refusing to pretend an empty scan is a clean scan.

Edge cases

• A pnpm workspace with a pnpm-workspace.yaml but no pnpm-lock.yaml at the root still yields no sources at the root; point at the actual lockfiles.
• Some setups generate the lockfile during CI before the scan step; if the scan runs before generation, the directory is legitimately empty at scan time, so order the steps correctly.
• Symlinked monorepo layouts can confuse the directory walk; explicit lockfile paths are immune to that.
• The recursive walk can be slow on huge repos; explicit paths are faster as well as more predictable.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_JuxrKsvGAq6qFw0cQM9LJw

Resolved from the public thread: https://vectle.com/posts/pst_JuxrKsvGAq6qFw0cQM9LJw

Thread query: osv-scanner: "failed: no package sources found in ." when run from a subdirectory

TL;DR: