LPM CLI

Migrating from Yarn

Convert a Yarn Classic or Berry project and review registry, protocol, and layout changes.

Use lpm migrate from the directory with package.json and yarn.lock. Yarn Classic and Berry lockfiles are supported.

LPM CLI works with npm, private registries, and LPM.dev Registry. Install it with the installation guide.

For a monorepo, run migration from the workspace root. Member-directory migration fails before it changes files.

--rollback can still restore an older migration from the member directory that contains its recovery files.

Preview and convert

Commit the current project before migration. Keep the previous package manager available for rollback.

lpm migrate --dry-run
lpm migrate

Read the detected source, skipped entries, warnings, and workspace count before conversion.

If several supported lockfiles exist, the newest modification time selects the input. There is no source-selection flag.

Equal timestamps prefer bun.lockb, bun.lock, pnpm-lock.yaml, yarn.lock, then package-lock.json. Other lockfiles stay in place.

Migration writes a staging lockfile, configures .npmrc, installs dependencies online, and runs available root build and test scripts.

The online install resolves the manifest requirements again. Migration does not guarantee the exact versions from the previous lockfile.

At a workspace root, installation includes the workspace members. Verification runs the root scripts. Use your usual workspace checks too.

Workspace hooks that request the same install lock fail with a parent-installation conflict. Run those commands after migration.

The command is non-interactive. An existing lpm.lock requires --force. --yes does not imply that flag.

Review Yarn-specific configuration

Migration does not translate .yarnrc.yml. Move required private-registry routing and credentials into supported .npmrc configuration.

Yarn Plug'n'Play loaders and the Yarn cache do not become LPM CLI's dependency layout. The install creates node_modules.

Remove PnP-specific loader settings from project commands only after you verify the replacement commands.

Classic integrity values can carry into staging. Berry cache checksums are not npm tarball integrity hashes. The online install obtains the required package integrity.

Some lockfile entries, including workspace:, portal:, patch:, and Git references, are skipped during import.

A skipped lockfile entry does not establish support for the matching manifest protocol. Review each dependency against npm compatibility.

Use supported workspaces and patches for equivalent workflows where applicable.

Simple resolutions can supply dependency overrides. lpm.overrides and npm overrides take precedence over resolutions.

Workspaces use isolated layout by default. Declare packages that the project imports instead of depending on undeclared packages from another workspace member.

Separate conversion from installation

For a conversion without dependency installation, verification scripts, or registry configuration:

lpm migrate --no-install --skip-verify --no-npmrc --no-ci --json

--no-install alone does not skip verification. Migration has no dedicated lpm.json fields.

The staging lockfile cannot support an offline or frozen install. Complete a mutable online install first:

lpm install --no-frozen-lockfile

The explicit flag also works where CI=true normally selects frozen installation.

Check the result

Run the project's existing checks, then replay the new lockfile:

lpm run build
lpm run test
lpm install --frozen-lockfile

Replace these script names with the checks that your project defines. lpm run preserves custom test commands and their arguments.

After the store contains every required package, you can check offline replay:

lpm install --frozen-lockfile --offline

--offline controls package-network work. Root lifecycle scripts can still contact the network.

Dependency scripts stay denied by default. Review blocked scripts before authorizing packages that require installation builds.

Commit the migration

Inspect the complete diff and the resolved dependency versions:

git status --short
git diff

Commit lpm.lock, .gitattributes, and the intended manifest, configuration, patch, and CI changes.

Review .npmrc before committing it. Store credentials in environment variables or a user-level file, not in the repository.

Keep .backup files and .lpm-migrate-manifest.json together until you accept the migration. Keep these recovery files out of commits.

Remove the old manager's tracked lockfile only after the team accepts the migration. Do not delete recovery snapshots to clean the Git diff.

For CI, replace the install step with lpm ci. Review generated templates before enabling them.

Roll back or retry

lpm migrate --rollback

Rollback restores or removes files recorded in .lpm-migrate-manifest.json. Other install changes, node_modules, store contents, and script output remain.

After rollback, run the previous manager's install command to restore its dependency layout.

For an install or verification failure, fix the reported cause before retrying:

lpm migrate --force

Repeated migration retains the first recovery snapshots. Keep them until you no longer need rollback.

See also