Explain package-lock.json code

What this package-lock.json sample shows

version and resolved

Each key is a folder npm creates, and version is the exact version that goes in it. package.json asks for a range, ^2.1.1, meaning 2.1.1 or any newer 2.x. The lock pins one answer, 2.1.1, so every npm ci installs that same version. resolved is the address the file was downloaded from.

integrity

integrity is a fingerprint of the downloaded file: its SHA-512 hash, written in base64. Downloading each of the 3 resolved files and hashing it gave exactly these values. With one character of the ms hash changed and an empty npm cache, npm ci stopped with EINTEGRITY and integrity checksum failed.

nested packages

debug 2.6.9 needs ms 2.0.0 exactly, but the project asked for ^2.1.1. Both can't sit in node_modules/ms, so npm gave debug its own copy at node_modules/debug/node_modules/ms. After npm ci, ms looked up from the project resolved to 2.1.1, and from debug's folder to 2.0.0.

npm ci and npm install

npm ci installs exactly what the lock says, or nothing. After is-odd was added to package.json but not to the lock, it stopped with EUSAGE, Missing: is-odd@3.0.1 from lock file and exit code 1. npm install with the same change worked out the new versions and added node_modules/is-odd and node_modules/is-number to the lock.

Good to know

• Run with npm 11.10.1 on Node 25.7.0, against the public npm registry. lockfileVersion 3, at the top of the full file, is the format npm 9 and later write.
• The sample leaves out the first 14 lines, which hold the project's own name and version, lockfileVersion and the ranges copied from package.json, and the 2 closing lines.

Watch out: Deleting the lock to make an error go away quietly changes your versions. With the lock gone, npm install picked ms 2.1.3, the newest version in the ^2.1.1 range, not the 2.1.1 the project had been running. Commit package-lock.json, and use npm ci on servers and in CI so they install what you tested.