fix: strip re-pinned devEngines.packageManager in lockfile/node_modules prepares; count pnpm 12 packages as pacquet

[zkochan]

What happened

Since ~Jun 18, npm, pnpm, and pnpm 12 (pacquet) have been DNF in every fixture of the lockfile, node_modules, and lockfile+node_modules variations (pnpm/pacquet in all fixtures except babylon; npm in the two fixtures that commit a .yarnrc.yml — next and babylon, since npm runs before berry/zpm write one). DNFs are charted at the slowest successful competitor's time, so these 15 cells and the averages page show pnpm 11/12 far slower than they actually are.

The install logs from the 2026-07-29 run show the failure:

-- Reading output of pnpm install 0 ---
[ERROR] This project is configured to use yarn
-- Reading output of pacquet install 0 ---
Error: ERR_PNPM_OTHER_PM_EXPECTED
  × This project is configured to use yarn

Root cause

Same one #118/#119 fixed for clean_all and the registry-lockfile prepare: the corepack yarn cache cleans inside clean_all_cache re-pin devEngines.packageManager (yarn) into the fixture's package.json. The per-run --prepare of these three variations runs clean_all_cache but never strips the field afterwards, so:

1. the pinned devEngines.packageManager: yarn survives into the timed run;
2. the npm pkg delete packageManager in the pnpm/pacquet setup silently fails too (npm refuses to run at all under a mismatched devEngines — EBADDEVENGINES);
3. npm/pnpm/pacquet exit 1 → DNF.

The three variations that clean caches per-run without re-stripping are exactly the three failing ones; every variation that either keeps its cache (cache*) or strips the field per-run (clean, cache+lockfile+node_modules, registry-lockfile) is green.

Fix (commit 1): run clean_package_manager_field at the end of the three BENCH_PREPARE_BASEs, after clean_all_cache — the same ordering clean_all documents.

Also: pnpm 12 package counts were attributed to pnpm

infer_package_manager in package-count.sh maps any pnpm-lock.yaml to pnpm, and both pnpm 11 and pnpm 12 leave one. So pacquet's counts were appended to pnpm-count.txt: pacquet had no package count at all (e.g. 2026-07-29/next-clean-package-count.json has no pacquet entry), breaking its per-package normalization, and pnpm's count mixed in pacquet's runs.

Fix (commit 2): both installers record their version in node_modules/.modules.yaml (packageManager: pnpm@<version>); treat major ≥ 12 as pacquet, keep pnpm as the fallback.

Tested locally: bash -n on all touched scripts; package-count.sh produces pacquet-count.txt for a .modules.yaml with pnpm@12.0.0-beta.0, pnpm-count.txt for pnpm@11.17.0, and falls back to pnpm when the file is absent.

---

Written by an agent (Claude Code, claude-fable-5) on behalf of @zkochan.

[lukekarrys]

thanks @zkochan!