Repository navigation
Yarn berry vendored and hosted modes refuse compressionLevel: 0 # comment in .yarnrc.yml as a non-default compression level #370
Description
[agent] Found by the scheduled Yarn Berry (2+) bug-hunt routine (ledger #305).
Summary
Suppose .yarnrc.yml sets compressionLevel: 0 with a trailing YAML comment, for example compressionLevel: 0 # keep yarn default. Yarn reads this as 0: yarn config get compressionLevel prints 0, and the lock's cacheKey is 10c0. socket-patch's flat-line reader takes the whole rest of the line, 0 # keep yarn default, as the value. So both vendored and hosted mode refuse the project as if it used a non-default compression level. The message contradicts itself:
vendor_yarn_berry_cache_unsupported: .yarnrc.yml sets `compressionLevel: 0 # keep yarn default`, which changes berry's cache checksums; only compressionLevel 0 (the yarn 4 default) is supported
redirect_yarn_berry_cache_unsupported: .yarnrc.yml sets `compressionLevel: 0 # keep yarn default`, …
Impact
A refusal fires on a supported configuration. vendor / scan --mode vendored / scan --mode hosted exit 1 and patch nothing for every npm purl in the project. Low severity, because it fails closed, but the only workaround is deleting the comment.
Repro (Linux, yarn 4.12.0 and 4.18.1)
echo '{"name":"app","version":"1.0.0","dependencies":{"left-pad":"1.3.0"}}' > package.json
printf 'nodeLinker: node-modules\nenableGlobalCache: false\ncompressionLevel: 0 # keep yarn default\n' > .yarnrc.yml
touch yarn.lock && yarn install
yarn config get compressionLevel # -> 0
grep cacheKey yarn.lock # -> cacheKey: 10c0
# stage .socket/manifest.json + blob for pkg:npm/left-pad@1.3.0
socket-patch vendor --json --offline # -> exit 1, vendor_yarn_berry_cache_unsupported
socket-patch scan --mode hosted … # -> exit 1, redirect_yarn_berry_cache_unsupported (mock API)Without the comment, the same project vendors, and passes a fresh yarn install --immutable with the patched bytes.
Expected vs actual
- Expected: docs/testing/yarn-berry-compatibility.md says cacheKey
10c0/compressionLevel: 0is supported, and the reader's doc comment says it should read the knob "the way yarn's YAML parser" does. A YAML comment isn't part of the scalar. - Actual: the comment is read as part of the value, and the supported config is refused.
Matrix
| OS | yarn | vendored | hosted |
|---|---|---|---|
| Linux (sandbox) | 4.12.0 | fails | fails |
| Linux (sandbox) | 4.18.1 | not run | fails |
The parser is OS-independent. Release 4.0.0 behaves the same (vendored checked).
Suspect code
crates/socket-patch-core/src/vendor/yarn_berry_lock.rs:1307 (yarnrc_compression_level: rest.trim().trim_matches(['\'', '"']) doesn't strip a #… comment). The hosted gate shares it.
Activity
mikolalysenko commentedon Sep 30, 2026
[agent] Triaged:
priority:p1(yarn berry, npm family). Not a duplicate, and I found no existing fix PR.The cause is
yarnrc_compression_levelinvendor/yarn_berry_lock.rs. It doesn't strip a YAML#comment from the scalar, and the hosted gate shares the same reader.Generated by Claude Code
mikolalysenko commentedon Oct 1, 2026
[agent] Re-triage on main
2463257(the v5 consolidation, #277): still reproduces. With yarn 4.12.0,.yarnrc.ymlcompressionLevel: 0 # defaultand a lock whosecacheKeyis10c0,scan --mode hostedreturnsredirected: 0withredirect_yarn_berry_cache_unsupported(".yarnrc.yml setscompressionLevel: 0 # default…"). The parser atcrates/socket-patch-core/src/vendor/yarn_berry_lock.rs:1351(yarnrc_compression_level) still takes the rest of the line verbatim, comment included.Generated by Claude Code
mikolalysenko commentedon Oct 1, 2026
[agent] Claiming this issue (single-issue cluster; root cause:
yarnrc_compression_levelkeeps a trailing YAML comment in the scalar). Branch: agent/fix-yarnrc-compression-comment. Claim-ID: 2026-10-01T22:21:17Z-81c1c3Generated by Claude Code
mikolalysenko commentedon Oct 1, 2026
[agent] Draft fix PR: #508
Generated by Claude Code
Read yarnrc compressionLevel past YAML comments