The warning means composer.json and composer.lock disagree: someone changed the requirements but did not refresh the lock file. Composer still installs what the lock file says. Fix it by running composer update deliberately, reviewing the diff, and committing both files together.
Why it appears
Composer stores a hash of the relevant parts of composer.json inside composer.lock. On install, it compares the two. If they differ, you get a warning that the lock file is out of date. The Composer docs note that install shows this warning when composer.lock is stale relative to composer.json.
Common causes:
- A developer edited a version constraint by hand and skipped
update. - A merge conflict in composer.lock was resolved by picking one side.
- A package was added to composer.json on one branch, and the lock file came from another.
Why you should not ignore it
A stale lock file means the versions on your servers may not match what composer.json now claims to allow. Reviewers reading composer.json see one thing, and production runs another. For a security review, that gap is exactly where an unreviewed package hides.
Steps to fix it
- Run
composer validateto confirm the problem. It checks composer.json and whether the lock file is up to date. - Run
composer updatefor the changed package, or the whole project if you intend to refresh everything. - Read the composer.lock diff.
- Commit composer.json and composer.lock in the same change.
- Make CI run validate so this cannot slip through again.
composer validate --strict
composer update vendor/package
git diff composer.lock
The strict option makes validate exit with a non-zero code on warnings as well as errors, which is what you want in a pipeline.
The hash only shortcut
composer update has a lock option that rewrites only the lock file hash, without changing package versions. The Composer docs describe it as a way to suppress the out of date warning. It is reasonable after you edit a field that does not affect resolution, such as the description. It is risky if you changed a real requirement, because the lock file would then claim to match when it does not.
Try it yourself
Click through it at your own pace, or open it full screen. See how a dependency inventory stays useful only while it matches what is deployed.
Where Safeguard fits
Safeguard's policies and gates can check dependency changes in a pull request before merge. A free scan shows what it finds today.
Quick check
Does the warning stop the install?
No, it is a warning. But treat it as a build failure in CI so the files stay in step.
Is a merge conflict in composer.lock safe to resolve by hand?
Avoid it. Take composer.json from the merged branch, then regenerate the lock file with update and review the result.
Sources
Last reviewed: 19 October 2026.
