Skip to content

feat(vendor): warn when a wired classic yarn.lock is one berry install from silent de-patching#133

Open
Mikola Lysenko (mikolalysenko) wants to merge 1 commit into
mainfrom
feat/classic-berry-migration-warning
Open

feat(vendor): warn when a wired classic yarn.lock is one berry install from silent de-patching#133
Mikola Lysenko (mikolalysenko) wants to merge 1 commit into
mainfrom
feat/classic-berry-migration-warning

Conversation

@mikolalysenko

Copy link
Copy Markdown
Collaborator

Why

Proven end-to-end during the strapi clean-run session: yarn 2+ (berry) migrates a classic (v1) yarn.lock on install and silently drops every vendored file:./.socket/vendor/… resolution — zero references survive the migration and all packages install unpatched from the registry, with no error or warning from yarn. A team with a classic-wired repo is one stray yarn@2+ install away from silently losing its patches.

What

  • Core probe vendor::yarn_classic_berry_migration_risk(project_root) — fires when yarn.lock is classic and carries vendored wiring and package.json lacks a packageManager: yarn@1… pin (a corepack pin makes stray berry installs refuse instead of migrate). The major version is parsed, so yarn@10 doesn't string-match yarn@1. State-based (reads the on-disk lockfile, not run events), so callers invoke it unconditionally at envelope-finalize: unwired projects, pinned projects, and fully-reverted runs stay silent.
  • New run-level warnings array on the JSON envelope ({code, detail}) for advisories about the project rather than any single package — omitted when empty, so existing consumers see byte-identical output. Human mode gets a stderr line.
  • Wired into the vendor command and both scan vendor flows (shared run_scan_vendor_step), emitting yarn_classic_berry_migration_risk with the pin remediation in the message.

Tests

  • 5 probe unit tests: warn without pin; yarn@1.22.22 pin suppresses; yarn@4/yarn@10/pnpm pins still warn (the yarn@10 case RED-guards the prefix-match bug); unwired/berry/missing lockfiles silent; malformed package.json fails toward warning.
  • The yarn-classic capstone e2e now asserts the advisory: present on first vendor and on in-sync re-runs; gone under a packageManager: yarn@1.22.22 pin (with the empty array omitted from JSON entirely); silent again after --revert.

Scope note

The hosted (redirect) classic wiring has the same berry-migration exposure — its warning belongs in the rewrite-warnings channel that flow already surfaces; left as a follow-up.

🤖 Generated with Claude Code

…l from silent de-patching

Proven end-to-end on a real monorepo (2026-07): yarn 2+ (berry)
migrates a classic (v1) yarn.lock to its own format on install and
re-resolves every entry from the registry — the vendored
`file:./.socket/vendor/…` resolutions are dropped with NO warning and
every package installs unpatched.

New state-based core probe `yarn_classic_berry_migration_risk`
(vendor/mod.rs): fires when yarn.lock is classic AND carries vendored
wiring AND package.json does not pin yarn classic via
`packageManager: yarn@1…` (a corepack pin makes stray berry installs
refuse instead of migrate; major is parsed, so yarn@10 does not
string-match yarn@1). Reads on-disk state, not run events, so callers
invoke it unconditionally at envelope-finalize: unwired projects,
yarn@1-pinned projects, and fully-reverted runs stay silent.

Surfaced as a new run-level `warnings` array on the JSON envelope
(`{code, detail}`, omitted when empty so existing consumers see
byte-identical output) plus a stderr line in human mode — wired into
the `vendor` command and both scan vendor flows (shared
run_scan_vendor_step).

Tests: 5 probe unit tests (pin suppression, yarn@4/yarn@10/pnpm pins
still warn, unwired/berry/missing locks silent, malformed package.json
fails toward warning); the yarn-classic capstone e2e now asserts the
advisory appears on first vendor AND on in-sync re-runs, disappears
under a yarn@1.22.22 packageManager pin (and the empty array is omitted
from JSON), and falls silent after --revert.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants