Time Remaining4:00
mediumDependenciesnpm

The stale lockfile

A developer asked an AI assistant to fix a bug by bumping a dependency to a newer, patched version. The suggested fix edits package.json's version range by hand and commits it, but a teammate who runs a fresh install right after still ends up with the old, buggy version installed.

bump.sh
# AI-suggested fix: manually edit package.json
sed -i 's/"left-pad": "1.3.0"/"left-pad": "1.3.1"/' package.json
git add package.json
git commit -m "Bump left-pad to 1.3.1 to fix padding bug"

Why does a teammate's fresh npm install right after this commit still install left-pad 1.3.0?

package-lock.json still pins the exact resolved version from before the edit — npm install honors the lockfile over package.json's range unless the lockfile itself is regenerated.
sed corrupts package.json's JSON formatting, so npm silently ignores the whole dependencies block.
git commit does not actually save changes to package.json unless package-lock.json is committed in the same commit.
npm always installs the latest published version of a package regardless of what package.json specifies.