Lockfiles

scpm's default lockfile for new projects is scpm-lock.yaml. For projects that already have a different supported lockfile, scpm keeps reading and writing that file in place.

Supported lockfile formats

scpm reads and writes all of the following formats:

scpm-lock.yaml (default for new projects)
pnpm-lock.yaml v9
package-lock.json
npm-shrinkwrap.json
yarn.lock — both v1 classic and v2+ berry
bun.lock

On install (and on add, remove, update, dedupe), scpm picks the lockfile to write from whichever supported file already exists in the project directory. Precedence is: scpm-lock.yaml → pnpm-lock.yaml → bun.lock → yarn.lock → npm-shrinkwrap.json → package-lock.json. When none of those exist yet, scpm writes scpm-lock.yaml.

The practical upshot:

A pnpm project keeps getting pnpm-lock.yaml updates.
An npm project keeps getting package-lock.json updates.
Only scpm import (or manually removing the existing lockfile) switches a project onto scpm-lock.yaml.

Keep the original lockfile while its package manager is still part of the workflow — scpm and the original package manager both read from and write to the same file without conflicting.

Frozen installs

scpm install --frozen-lockfile
scpm ci

Frozen mode fails when the lockfile no longer matches the manifest.

Prefer frozen installs

scpm install --prefer-frozen-lockfile

This is the local default. scpm uses the lockfile if it is fresh and re-resolves when the manifest changed.

Lockfile-only updates

scpm install --lockfile-only

Use this when CI or automation needs to update dependency metadata without touching node_modules.

Branch lockfiles