Skip to content

test(vendor): yarn 1 dev-flow e2e — lockfile re-save survival + strapi-incident guards#129

Open
Mikola Lysenko (mikolalysenko) wants to merge 1 commit into
mainfrom
test/vendor-yarn1-dev-flow-e2e
Open

test(vendor): yarn 1 dev-flow e2e — lockfile re-save survival + strapi-incident guards#129
Mikola Lysenko (mikolalysenko) wants to merge 1 commit into
mainfrom
test/vendor-yarn1-dev-flow-e2e

Conversation

@mikolalysenko

Copy link
Copy Markdown
Collaborator

Why

Debugging a vendored-mode install of an old strapi monorepo (yarn v1 lockfile) surfaced a class of yarn-1 flows our existing capstone doesn't cover. The install failures themselves turned out to be a yarn 2.4.3 bug on Node ≥23 (util.isDate removed; berry's builtin patch: compat fetcher for fsevents/resolve crashes — unrelated to our wiring), but the incident showed yarn 1 is the right installer for classic-lockfile projects — and we only e2e-proved the --frozen-lockfile --offline fresh-checkout path (e2e_vendor_yarn_classic_build.rs).

Manually verified during the incident, now pinned as e2e: yarn 1.22.22 consumes vendored file: wiring correctly in the everyday developer flows, where a regression would silently drop patches.

What the new capstone proves (e2e_vendor_yarn_classic_dev_flow.rs)

  1. Plain yarn install (no --frozen-lockfile, no --offline) on a fresh checkout delivers the patched bytes and keeps the vendored block intact.
  2. yarn add re-serialization round-trip: yarn add rewrites the entire lockfile from yarn's in-memory model (asserted via Saved lockfile. so the check can't go vacuous). The vendored resolved "file:./.socket/vendor/…#sha1" + recomputed integrity block must survive byte-intact.
  3. Unpatched-neighbor coexistence: resolve@1.20.0 (the package at the center of the strapi incident — berry builtin-patches it) rides along unvendored; its lock block stays byte-identical through vendor + installs and it installs pristine registry bytes.
  4. No patch: protocol leakage: the wired/re-saved lockfile never contains a patch: resolution, so a berry migration of a classic lockfile can never inherit one from us.
  5. Frozen re-entry: --frozen-lockfile passes on the re-saved lockfile — dev installs don't wedge CI installs downstream.
  6. Lockfile fixpoint: repeated plain installs leave yarn.lock byte-identical.

Conventions

Same harness shape as the existing capstone: self-contained helpers, corepack yarn@1.22.22 pinned, SOCKET_* env scrubbed, private YARN_CACHE_FOLDER per phase, local-only skip gates (corepack/registry unavailable → println + return), hard assertions after the gate.

Test run

VENDOR OK
DEV INSTALL OK
YARN ADD RE-SERIALIZATION OK
FIXPOINT OK
FROZEN RE-ENTRY OK
test yarn_classic_vendored_lock_survives_dev_install_resave ... ok

🤖 Generated with Claude Code

…coexistence, no patch: leakage

Companion to the fresh-checkout capstone (e2e_vendor_yarn_classic_build):
proves yarn 1.22.22 stays a first-class installer for vendored wiring
across the everyday flows that capstone does not exercise:

- plain `yarn install` (no --frozen-lockfile/--offline) delivers patched
  bytes and keeps the vendored file: block intact
- `yarn add` re-serializes the ENTIRE lockfile from yarn's in-memory
  model (asserted via `Saved lockfile.`) and must round-trip the
  vendored block byte-intact — the flow that would silently drop
  patches if yarn normalized our entry away
- an unvendored neighbor (`resolve` — the package at the center of the
  strapi/yarn2 incident) keeps a byte-identical lock block and installs
  pristine
- the wired lockfile never contains a `patch:` resolution (guards berry
  migrations of classic lockfiles)
- `--frozen-lockfile` passes on the re-saved lockfile (CI re-entry)

Local capstone: skips when corepack/registry are unavailable; all
assertions after the gate are hard.

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.

1 participant