npm ci lockfileVersion reproducibility across versions

npm ci lockfileVersion mismatch across npm releases

0 reputation · 22 Apr 2022, 06:18 UTC

123.3K views0

A team wants a single package-lock.json to drive identical installs with npm ci across local workstations and CI runners.

npm records lockfileVersion in the lockfile, and npm 7 and later use version 2 or 3 while earlier releases use version 1. It is unclear whether npm ci rejects a lockfile written by a different major npm release, or whether it silently rewrites the lockfile during installation. The --prefer-offline flag is intended to avoid network calls, but it is not clear whether cached packages skip integrity hash validation against the lockfile.

Does npm ci fail when lockfileVersion differs from the running npm version's expected format? Does npm ci update package-lock.json when installed from an older lockfileVersion? With --prefer-offline, does npm ci still verify package integrity hashes from package-lock.json?

Keep exploring this topic

package-lock.json migration from npm v6 to v7+ lockfileVersion 2

Exploring how to manage the automatic migration of package-lock.json to lockfileVersion 2 when transitioning from npm v6 to v7+ in mixed-version environments.

Lockfile mismatch failure during npm ci execution

An analysis of the lockfile validation failure in npm ci and the decision between failing fast on manifest drift versus using npm install for self-healing pipelines.

npm deprecation warnings are advisory and do not block install

npm surfaces deprecation warnings but does not block install, leaving the decision to upgrade or accept risk to the project. How to codify a policy for deprecated dependencies while preserving lockfile determinism.

Commit composer.lock to version control or risk version drift after backup restoration?

Deciding whether to include composer.lock in backups and version control affects reproducibility after vendor directory restoration.

The lockfileVersion integer is not the only compatibility gate. npm 6 writes version 1 lockfiles without the top-level packages map that npm 7+ uses during npm ci, so a newer client can read the file yet still abort or resolve a different tree. npm ci never silently rewrites the lockfile. For --prefer-offline, integrity hash validation still runs against cached tarballs; it only changes download preference. Confirm with git diff package-lock.json after a scratch install.

npm ci lockfileVersion mismatch across npm releases

0 answers

Your perspective belongs here.

1 question comment