Best Practices Migration

v11 changes how configuration is read. Most of it is mechanical — run the codemod:

The codemod automatically:

• Moves package.json#pnpm settings into pnpm-workspace.yaml (the pnpm field is no longer read).
• Splits .npmrc: only auth/registry settings stay in .npmrc; every other key moves to pnpm-workspace.yaml as camelCase (e.g. node-linker → nodeLinker). Per-subproject .npmrc files become packageConfigs["<name>"].
• Consolidates build settings (onlyBuiltDependencies, neverBuiltDependencies, ignoredBuiltDependencies, onlyBuiltDependenciesFile) into one allowBuilds: { name: true|false } map.
• Replaces managePackageManagerVersions/packageManagerStrict/packageManagerStrictVersion with pmOnFail: download|ignore|warn|error.
• Renames allowNonAppliedPatches → allowUnusedPatches, auditConfig.ignoreCves → auditConfig.ignoreGhsas.
• Converts useNodeVersion → devEngines.runtime, and bumps packageManager.

Manual follow-ups (not automatable):

• Convert CVE-… IDs to GHSA-… in auditConfig.ignoreGhsas.
• ignorePatchFailures removed — failed patches now always throw.
• npm_config_* env vars → pnpm_config_* (CI, shell profiles, Docker).
• pnpm link <name> → use a path (pnpm link ./foo); pnpm link --global → pnpm add -g ..
• pnpm install -g (no args) and pnpm server removed.
• A package.json script named clean/setup/deploy/rebuild now shadows the built-in — use pnpm pm <name> for the built-in.

Migrating from npm / Yarn

Quick Migration

From npm

From Yarn

Import Existing Lockfile

pnpm can import existing lockfiles:

Handling Common Issues

Phantom Dependencies

pnpm is strict about dependencies. If code imports a package not in package.json, it will fail.

Problem:

Solution: Add missing dependencies explicitly:

Missing Peer Dependencies

pnpm reports peer dependency issues by default.

Option 1: Let pnpm auto-install (default in v8+):

Option 2: Install manually:

Option 3: Suppress warnings if acceptable:

Symlink Issues

Some tools don’t work with symlinks. Use hoisted mode:

Or hoist specific packages:

Native Module Rebuilds

If native modules fail, try:

Monorepo Migration

From npm Workspaces

1. Create pnpm-workspace.yaml:

   yamlCopy

   packages:
     - 'packages/*'

2. Update internal dependencies to use workspace protocol:

   jsonCopy

   {
     "dependencies": {
       "@myorg/utils": "workspace:^"
     }
   }

3. Install:

   bashCopy

   rm -rf node_modules packages/*/node_modules package-lock.json
   pnpm install

From Yarn Workspaces

1. Remove Yarn-specific files:

   bashCopy

   rm yarn.lock .yarnrc.yml
   rm -rf .yarn

2. Create pnpm-workspace.yaml matching workspaces in package.json:

   yamlCopy

   packages:
     - 'packages/*'

3. Update package.json - remove Yarn workspace config if not needed:

   jsonCopy

   {
     // Remove "workspaces" field (optional, pnpm uses pnpm-workspace.yaml)
   }

4. Convert workspace references:

   jsonCopy

   // From Yarn
   "@myorg/utils": "*"
   
   // To pnpm
   "@myorg/utils": "workspace:*"

From Lerna

pnpm can replace Lerna for most use cases:

Configuration Migration

Keep only auth/registry in .npmrc; put everything else in pnpm-workspace.yaml (camelCase).

Scripts Migration

Most scripts work unchanged. Update pnpm-specific patterns:

CI/CD Migration

Update CI configuration:

Add to package.json for Corepack:

Gradual Migration

For large projects, migrate gradually:

1. Start with CI: Use pnpm in CI, keep npm/yarn locally
2. Add pnpm-lock.yaml: Run pnpm import to create lockfile
3. Test thoroughly: Ensure builds work with pnpm
4. Update documentation: Update README, CONTRIBUTING
5. Remove old files: Delete old lockfiles after team adoption

Rollback Plan

If migration causes issues:

Keep old lockfile in git history for easy rollback.