GeezerVison

LLM Description written by Claude Code:claude-opus-5-5

Fixes #754

Summary

Vendoring a pnpm 7/8 project (lockfile 5.4 / 6.0) writes the project's
absolute path into pnpm-lock.yaml as the root dependency's
specifier. When that path contained # or : (e.g.
~/src/My Project #2), the value was written unquoted, so YAML cut it
short at # or rejected the line at : . Every
pnpm install --frozen-lockfile then failed at the very path the
lock was written for, while vendor reported success. The specifier
is now written the way pnpm itself writes it: plain when safe,
single-quoted otherwise (double-quoted with escapes for characters
single quotes can't carry).

Root cause

vendor/pnpm_lock_legacy.rs spliced file:<abs root>/<tgz> into the
specifiers: line (5.4) and the nested specifier: line (6.0) with
format!, never encoding it as a YAML scalar. The in-sync checks
compared that same raw text, so a re-run agreed with the broken write.

Changes

• formats/pnpm/lines.rs: new yaml_value, which spells a mapping
  value the way pnpm's writer (js-yaml dump) does.
• vendor/pnpm_lock_legacy.rs: both specifier writers and their
  in-sync checks use the encoded spelling. Ownership checks read the
  unquoted value. Revert recognizes our own value in quoted form too.
• A lock that an older release left broken (the unquoted spelling) is
  not treated as in sync. Re-running vendor rewrites it to the
  quoted spelling, records no "original" for our own stale value, and
  the first ledger entry still reverts byte-for-byte.

Test evidence

The e2e legs run the existing legacy capstone (vendor, same-path
--frozen-lockfile --offline install of the patched bytes, moved
checkout, idempotent re-vendor, byte-exact revert) in hash #x and
colon: x project dirs (colon: x on unix only: Windows forbids : in a
path component). The red runs used this branch's tests with
origin/main's writer.

Commands run locally (Linux):

• cargo fmt --all -- --check: clean
• cargo clippy --workspace --all-features -- -D warnings: clean
• cargo test -p socket-patch-core --lib -- pnpm_lock_legacy formats::pnpm: 80 passed
• cargo test -p socket-patch-cli --test e2e_vendor_pnpm_build -- real_lifecycle: 4 passed
• cargo test --workspace --all-features --no-fail-fast: the only failures are
  the permission and self-update tests that fail when run as root in this
  sandbox (chmod-0555 / unremovable-file write-failure cases, self-update
  lock/state-dir legs). None touch pnpm; CI runs them as non-root.

No wrapper changes: this is Rust-only lock surgery, and the npm, pypi
and gem wrappers only dispatch to the binary.

Notes

• vex never reads importer specifiers (vex/discover/npm.rs), and on
  main vendor --check checks only the committed artifact for npm-family
  entries. With the write fixed, both report a lock that installs.
  Teaching vendor --check to re-verify npm-family wiring is the
  general gap tracked in vendor --check says "committed artifact and wiring verified" (exit 0) after pipenv lock drops the vendored reference, so a fresh pipenv install --deploy installs the unpatched wheel while vex says vendor_unwired #725 / Fix vendor --check passing unwired vendored entries (#725) #730.
• pnpm >= 9 vendored locks use only relative specifiers and aren't
  affected.

🤖 Generated with Claude Code

https://claude.ai/code/session_01WrJKfSVrc5xqCq2bHEQsUA

Generated by Claude Code