The Lockfile

A package.json (or Cargo.toml) records what you ASKED FOR (^4.18.0). A lockfile records what you GOT (4.18.2).

package.json:        Cargo.toml:
"express": "^4.18.0" express = "4.18"

package-lock.json:   Cargo.lock:
"express": {         [[package]]
  "version": "4.18.2", name = "express"
  ...                version = "4.18.2"
}

Why lockfiles matter:

• Reproducible builds: npm install on Tuesday and Friday should produce the same files.
• Deterministic CI: tests against the exact same versions every time.
• Security audits: pin specific known-good versions until you upgrade deliberately.

Without a lockfile: ^4.18.0 might resolve to 4.18.2 today and 4.19.0 tomorrow if the maintainer publishes. Different CI runs use different code. Bug bisect: nightmare.

Lockfile contents:

• Exact version of every transitive dep
• Resolved URL / registry
• Integrity hash (SHA-512 SRI)
• Sometimes the dep tree shape

Lockfile semantics:

• npm install USES the lockfile if present (only adds new deps)
• npm install <pkg> updates the lockfile for that package
• npm update re-resolves within constraints (may bump within ^range)
• npm ci REQUIRES the lockfile; fails if missing or out of sync
• cargo build always uses the lockfile

Best practice: COMMIT the lockfile to your repo. Even for libraries (recent recommendation flip — used to be "don't commit for libs", now generally yes).