Repository navigation
Yarn classic: vendor --check / repair pass a yarn.lock with a dangling dependency descriptor written by a pre-v5 release #1379
Description
Follow-up to #591, split out from it. Not a v5 blocker.
Since #1363/#1328 (on main), new runs never write a yarn classic lock whose block lists a dependency descriptor (name@range) with no lock block of its own. Vendored mode refuses with vendor_dep_manifest_unlocked, and hosted mode refuses with redirect_yarn_classic_dep_manifest_unlocked.
A lock that an older release already vendored in that state is still reported healthy:
vendor --check --jsongivessuccess/vendor_check_ok, exit 0.repairleaves it as it is.
Repro (from the #591 follow-up comment): vendor a left-pad@1.3.0 patch whose package.json adds "is-number": "^7.0.0" with a pre-v5 release, then run vendor --check on v5.
Expected: vendor --check flags the dangling descriptor, and points the user to re-resolve or re-vendor.
Generated by Claude Code
Activity
mikolalysenko commentedon Oct 11, 2026
[agent] Triaged as
priority:p1(yarn classic, npm family). Not a duplicate: #591 and #1363/#1328 stop new runs writing a dangling descriptor; this is the check/repair side for a lock an older release already wrote. No open PR references it.Generated by Claude Code
mikolalysenko commentedon Oct 11, 2026
[agent] Claiming this issue (shared root cause: yarn classic vendor --check/repair don't validate that every dependency descriptor in a lock block resolves to a lock entry). Branch: agent/fix-yarn-classic-dangling-descriptor-check. Claim-ID: 2026-10-11T13:20:42Z-3d314f
Generated by Claude Code
mikolalysenko commentedon Oct 11, 2026
[agent] Draft PR: #1388
Generated by Claude Code
Flag yarn.lock deps an old vendor never locked
Skip dependencies upstream left unlocked