## 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

```text
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

```bash
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

```bash
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