Use when starting a migration of an existing Yarn Classic 1.x repository or subdirectory to pnpm, or auditing a Yarn-to-pnpm PR for exact transitive package version drift across yarn.lock, pnpm-lock.yaml, package-manager list output, and node_modules. Triggers include "yarn classic to pnpm", "pnpm migration", "Yarnからpnpm移行", "既存Yarn repoをpnpm化", "lockfile drift", "孫パッケージのバージョン一致", and "pnpm importで一致するか確認".
Instalar com Codex ou Claude Copie este prompt, cole no Codex, Claude ou outro assistente e deixe que ele revise a página da skill e instale para você.
Um comando direto ignora o prompt de revisão. Verifique a origem antes de executá-lo.
Use when starting a migration of an existing Yarn Classic 1.x repository or subdirectory to pnpm, or auditing a Yarn-to-pnpm PR for exact transitive package version drift across yarn.lock, pnpm-lock.yaml, package-manager list output, and node_modules. Triggers include "yarn classic to pnpm", "pnpm migration", "Yarnからpnpm移行", "既存Yarn repoをpnpm化", "lockfile drift", "孫パッケージのバージョン一致", and "pnpm importで一致するか確認".
This skill migrates an existing Yarn Classic 1.x repo/subdir to pnpm, then verifies whether every transitive package version was preserved. If not, it makes every drift visible and reviewable.
Use the bundled verifier during the migration; do not rely on intuition, pnpm import, or passing tests as proof.
Core Rule
The acceptable outcomes are only:
Prove exact (package name, version) equality through grandchildren and deeper packages, or
Show every mismatch, classify it, and identify the small set that needs runtime monitoring.
In real pnpm migrations, outcome 2 is common. Say "complete match" only if the script proves it.
Inputs
The user should provide one or more Yarn Classic project roots. Each root is a directory containing package.json and usually yarn.lock.
Examples:
.
server
global-app
global-app/server
If the user names a repo root and it contains nested Yarn lockfile units, discover them with:
find <repo> -path -prune -o -name yarn.lock -
'*/node_modules'
print
Treat each yarn.lock directory as an independent migration unit unless the repo already has a workspace design that says otherwise.
Migration Workflow
For each Yarn Classic project root:
Inspect current state:
git status --short
sed -n '1,220p' <root>/package.json
test -f <root>/.npmrc && sed -n '1,120p' <root>/.npmrc || true
Validate the existing Yarn lockfile before changing anything:
This means zod still exists, but the Yarn-side zod@4.x line disappeared. It may be semver-legal if the depender accepts ^3.25 || ^4, but it is not "nothing"; it is a runtime review item.
Risk Triage
Use this order:
MISSING_NAME in production dependency paths: highest priority.
MAJOR_COLLAPSED in production dependency paths: high priority.
OS optional binaries like @esbuild/<os>-<arch> and @rollup/<os>-<arch>: usually build/runtime-environment dependent, not app logic.
Dev/build/test tooling such as esbuild, rollup, @typescript-eslint/*, @jridgewell/*: rely on typecheck/test/build-style gates, but still list them.
npm alias differences: accept only when ALIAS_TO real@version is present and the real package exists on pnpm side.
For Test Maker's observed migration, the practical conclusion was:
Complete equality was false.
Most drift was optional OS binaries, dev/build tooling, patch/minor consolidation, or Yarn duplicate-version collapse.
Strong runtime watch item: server/zod major collapse through @modelcontextprotocol/sdk / zod-to-json-schema.
Light smoke items: @opentelemetry/* for Sentry tracing, @grpc/proto-loader for Firebase/Admin/Firestore path.
pnpm import Guidance
pnpm import is useful and should generally be tried early, but do not claim it proves equality.
Reasons:
pnpm and Yarn Classic model peer dependencies and optional dependencies differently.
Adding pnpm.overrides, changing .npmrc, or reinstalling after import can re-resolve transitive packages.
The final pnpm-lock.yaml must still be compared mechanically against the old yarn.lock.
If a PR did not use pnpm import, you may create a throwaway branch/worktree and try it as a counterfactual. Still judge by verifier output, not by import intent.
Report Template
Use this shape in PR descriptions or initiative reports:
## Yarn -> pnpm dependency drift audit
Conclusion:
- Exact transitive version equality: NO
- All drift mechanically visible: YES
- Runtime watch items: <shortlist>
Primary lockfile comparison:
<pasteall-lockstable>
Local node_modules comparison:
<pasteall-node-modulestable>
Interpretation:
- Most drift is <optionalOSbinaries / devtooling / patch-minorconsolidation / Yarnduplicate-versioncollapse>.
- Strong check required:
- <package>: <why, path, command used to verify>
- Light smoke:
- <packagegroup>: <scope>
Reproduction:
<commandsanotherterminalcanrun>
Completion Checklist
Before saying the migration audit is done:
A pre-migration Yarn worktree exists or old yarn.lock files were extracted from the target branch.
yarn install --frozen-lockfile succeeded for every Yarn lockfile unit being compared.
all-locks or equivalent per-lock lock commands were run.
node-modules or all-node-modules was run if local installed reality matters.
If list-json is used, yarn_only counts match lockfile comparison, or the discrepancy is explained.
Every MISSING_NAME and MAJOR_COLLAPSED production-path item has an explicit interpretation.
