`vp install` rejects a Corepack-written `packageManager` pin: vp hashes the .tgz, Corepack hashes the extracted binary

[nazar-ch]

Describe the bug

vp install rejects a valid Corepack-written packageManager pin with a Hash mismatch error, because vp and Corepack hash different artifacts for the same package manager release.

error: Hash mismatch: expected sha512.ccbfabf7…4697, got sha512.dad89242…a9ea

• expected is verbatim the packageManager pin in package.json, written by corepack use yarn@….
• got is the sha512 of the .tgz tarball — it equals @yarnpkg/cli-dist@4.17.1's npm dist.integrity exactly.
• Corepack's hash is the sha512 of the extracted yarn.js, not the tarball.

Verified on yarn 4.17.1:

sha512(~/.cache/node/corepack/v1/yarn/4.17.1/yarn.js) = ccbfabf7…4697   ← Corepack's basis, == the pin
sha512(cli-dist-4.17.1.tgz)                           = dad89242…a9ea   ← vp's basis, == npm dist.integrity

The payloads are identical — the cached yarn.js is byte-for-byte the file inside the published tarball (both sha256 471ffb15…, 3 019 751 bytes). Nothing is tampered with; only the hash basis differs.

This is symmetric, so the two tools are mutually exclusive: if I rewrite the pin to vp's tarball hash, vp install passes and a cold-cache corepack install fails with the mirror-image error:

Internal Error: Mismatch hashes. Expected dad89242…a9ea, got ccbfabf7…4697
    at installVersion (…/corepack/dist/lib/corepack.cjs:13262:11)

No hashed value satisfies both, which is a problem for any repo whose Docker images run corepack install while developers run vp install. Since Corepack is what writes the +sha512. suffix, and #195 describes the feature as "Support Corepack-style packageManager format with integrity hashes", vp's basis looks like the unintended one.

The source appears to hash the tarball before extraction, in crates/vite_install/src/request.rs:

client.download_file(url, &tgz_file).await?;

// Verify hash if provided
if let Some(expected_hash) = expected_hash {
    verify_file_hash(&tgz_file, expected_hash).await?;
}

Only reproduces on a cold package-manager cache. Once ~/.vite-plus/package_manager/yarn/<version>/ exists, vp install succeeds with the very same pin it rejected a moment earlier, so verification appears to be skipped on a cache hit. That contradicts #195's "Re-verify cached packages when hash is provided", and it makes the bug look intermittent — CI and fresh containers fail while a warm dev machine passes.

Expected behavior: verify the packageManager integrity against the same artifact Corepack hashes (the extracted binary), so a pin written by corepack use validates under vp install. If hashing the tarball is deliberate, it would help to say so in the error, since the current message reads as a corrupted download.

Workaround: drop the +sha512.… suffix and pin "packageManager": "yarn@4.17.1", which both tools accept — at the cost of the integrity check.

Reproduction

No repository needed — the repro is a package.json with two fields, given in full below.

Steps to reproduce

mkdir vp-hash-repro && cd vp-hash-repro
cat > package.json <<'EOF'
{
  "name": "vp-hash-repro",
  "private": true,
  "packageManager": "yarn@4.17.1+sha512.ccbfabf7d7b6b32075088be9386fb9a2e00bb6887ef07fa56effabc890a56d53da1ccc4128d62db245fcbd3961b236d75335bdf7d5320ed6eafb7588b7ad4697"
}
EOF

# the pin above is what `corepack use yarn@4.17.1` writes; Corepack accepts it:
corepack install     # → "Adding yarn@4.17.1 to the cache..."
yarn --version       # → 4.17.1

# ensure a cold vp package-manager cache, or the check is skipped:
rm -rf ~/.vite-plus/package_manager/yarn/4.17.1 ~/.vite-plus/package_manager/yarn/4.17.1.lock

vp install           # → error: Hash mismatch: expected sha512.ccbfabf7…, got sha512.dad89242…

To confirm the two bases directly:

shasum -a 512 ~/.cache/node/corepack/v1/yarn/4.17.1/yarn.js   # → ccbfabf7…  (Corepack / the pin)
curl -sL https://registry.npmjs.org/@yarnpkg/cli-dist/-/cli-dist-4.17.1.tgz | shasum -a 512
                                                              # → dad89242…  (vp / npm dist.integrity)

System Info

$ vp env current
Environment:
  Version       26.5.0
  Source        devEngines.runtime
  Source Path   /…/package.json
  Project Root  /…

Tool Paths:
  node  ~/.vite-plus/js_runtime/node/26.5.0/bin/node
  npm   ~/.vite-plus/js_runtime/node/26.5.0/bin/npm
  npx   ~/.vite-plus/js_runtime/node/26.5.0/bin/npx

Package Manager:
  Name          yarn
  Version       4.17.1
  Source        packageManager
  Source Path   /…/package.json
  Project Root  /…
  Bin Path      ~/.vite-plus/package_manager/yarn/4.17.1/yarn/bin/yarn

$ vp --version
vp v0.2.2

Local vite-plus:
  vite-plus  v0.2.0

Corepack 0.35.0 · Node 26.5.0 · macOS 26.5.2 (arm64)
Also reproduced on Linux aarch64 with vp v0.2.1 / yarn 4.14.1 (pin `sha512.64df4480…`, vp computed `sha512.eb6b9844…` = that release's npm `dist.integrity`), so it is neither platform- nor version-specific.

Used Package Manager

yarn

Validations

• Read the Contributing Guidelines.
• Check that there isn't already an issue for the same bug.
• Confirm this is a Vite+ issue and not an upstream issue (Vite, Vitest, tsdown, Rolldown, or Oxc).
• The provided reproduction is a minimal reproducible example.