yarn.lock (v1) cataloger silently returns 118 of 745 packages — most entries dropped without error

[c-schmitz]

What happened

Scanning a single, valid Yarn v1 yarn.lock (one # yarn lockfile v1 header, 745 resolved packages), Syft catalogs only 118 npm packages and reports no warning or error. The very first entry (@ampproject/remapping@2.2.0) and the entire @babel/* set are missing from the output.

foundBy is javascript-lock-cataloger reading /yarn.lock, so the file is being parsed — the majority of entries are simply dropped.

Environment

syft 1.51.0
BuildDate:      2026-08-10T14:48:50Z
Platform:       linux/amd64
GoVersion:      go1.26.3
SchemaVersion:  16.1.10

Steps to reproduce

Uses a public, unmodified lockfile from the LimeSurvey repository:

mkdir /tmp/syft-yarn-repro && cd /tmp/syft-yarn-repro
curl -sSLO https://raw.githubusercontent.com/LimeSurvey/LimeSurvey/2bcfc80760734c0339f08a4fec445f53ffcaaab5/assets/packages/adminbasics/yarn.lock

# It is a single, valid v1 lockfile:
grep -c '# yarn lockfile' yarn.lock      # => 1
grep -c '^  version "' yarn.lock          # => 745  (resolved packages)

# Syft only catalogs 118:
syft scan dir:. -o syft-json \
  | jq '[.artifacts[] | select(.type=="npm")] | length'          # => 118  (expected ~745)

# The first entry in the lockfile is dropped entirely:
syft scan dir:. -o syft-json \
  | jq -r '.artifacts[] | select(.type=="npm") | .name' \
  | grep -x '@ampproject/remapping'                               # => (empty)

Expected behavior

All ~745 resolved packages from the yarn.lock are cataloged (or, at minimum, a warning is emitted if some entries cannot be parsed).

Actual behavior

Only 118 npm packages are returned, silently. No error or warning is produced, even at -vv.

Additional diagnostics

• Debug run (-vv) shows no parse errors/warnings for the lockfile.
• Not a cataloger restriction: syft config --load reports default-catalogers: [] and select-catalogers: []; there is no .syft.yaml present.
• The file is clean ASCII, no CRLF; version count and resolved count both equal 745.
• Both scoped and unscoped entries are affected:
  • Survivors: 2 scoped + 116 unscoped = 118
  • Lockfile total: 163 scoped + 577 unscoped = 740 header lines (745 resolved versions).
• Examples of packages kept: ansi-colors, arr-diff, base, cache-base, class-utils, collection-visit, color-convert, @babel/parser.
• Examples of packages dropped: @ampproject/remapping, @babel/core, and most of @babel/*.
• Scanning the directory alone (syft scan dir:.) reports foundBy = javascript-lock-cataloger with location /yarn.lock, confirming the yarn.lock is the source and the loss happens during parsing.

Impact

SBOMs generated from projects that use this (common) yarn.lock shape under-report dependencies by ~84%, silently breaking dependency inventory and downstream vulnerability scanning (e.g. Grype).

[sidsri14]

I attempted to reproduce this drop with the exact reporter environment and the attached lockfile, and I'm not seeing it — all 745 packages are cataloged.

Reproduction setup:

• Binary: syft v1.51.0, linux/amd64, GitCommit 2293641e3bd628a01bb37639318d62c0ebe89b39, GoVersion go1.26.3 (matches the syft version reported here).
• Lockfile: sha256 3c4129daad9e1ec42d38ac7812d5fc45c167b9193b5422b1f9d5b42f4ebb4e14, LF-only, 745 version entries.
• Command: syft yarn.lock -o json (exit 0)

Results:

Environment	npm artifacts
v1.51.0 linux/amd64	745
v1.51.0 windows/amd64	745
current main (39c9c690d, built locally)	745

The SBOM contains all 745 npm artifacts; @ampproject/remapping and @babel/core are present. I traced the v1 parser (parseYarnV1LockFile) and it is deterministic sequential line parsing that can't drop 118 entries from this file.

Could you share a bit more so I can keep chasing this?

• The exact command you ran (a directory scan vs. a single lockfile, and any flags like --scope).
• The full syft version output and your syft config (or config file), in case a cataloger option differs.
• A -vv log from the failing scan.
• Whether this is a monorepo with multiple yarn.lock files or a single workspace root.

The 118 count is very specific, so I suspect the reproduction depends on one of the above rather than the parser.

[CAOShurong]

Reproduced on current main (bf82010f, go1.26.6, Windows) by driving parseYarnV1LockFile / genericYarnLockAdapter.parseYarnLock directly against the same LimeSurvey lockfile:

• raw parser output: 745 entries, 0 with missing name/version — parsing is not where entries are lost
• adapter, default config: 111 emitted (745 − 634 classified dev-only)
• adapter with include-dev-dependencies: true: 745 emitted

So the entries are dropped by the dev-dependency reachability filter introduced in #4548, not lost during parsing. Mechanism: findDevOnlyPkgs walks a BFS from the adjacent package.json's declared dependencies/devDependencies through only the dependencies: edges recorded in yarn.lock. The root package.json here declares 4 prod deps and 33 dev deps, so everything connected only through dev paths is removed — silently. (The reporter saw 118 on 1.51.0 vs my 111 on main; likely minor name@version dedup differences between versions, same mechanism.)

Two things make this sharper than "works as intended":

1. Unlike package-lock.json, where each entry carries an explicit dev: true flag so dropping is data-grounded, a yarn v1 lockfile records no scope per entry — the filter is an inference over an undifferentiated graph, applied to 85% of this file.
2. The name-keyed lookup in findDevOnlyPkgs keeps only the last entry per name, so with multiple versions of one name (109 duplicated version-lines in this lockfile) dependency edges from shadowed entries disappear from the walk. Measured here: the prod-reachable name set is 29 with last-wins vs 31 using union-of-edges across all instances — small in this case, but classification is instance-dependent rather than stable.

The reported "expected 745" assumes no filtering at all; syft's documented default since #4548 is prod-only, so the count gap itself matches that design. What looks like a genuine defect is the silence around a lossy inference, plus the instability in point 2. Options in increasing scope:

• log a warn/debug line with dropped/kept counts when the filter discards a large fraction of parsed entries;
• build pkgByName from union-of-edges across same-name instances so multi-version shadowing cannot flip classification;
• revisit scope inference for v1 entirely (closer to how berry entries are treated) — a behavior change affecting yarn lockfile scan doesnt catch dev dependencies #4548 users, so maintainer call.

Happy to prepare a PR for whichever fits; the second option is contained and I can validate it against this fixture plus the existing javascript cataloger suite.