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

Include composer.lock in version control and in your backups; this guarantees that restoring the vendor directory reproduces the exact dependency versions recorded in the lock file, preventing version drift.

Explanation

Composer uses composer.lock to lock the resolved versions of all packages. When you run composer install, it reads the lock file and installs the exact versions, ignoring any changes in composer.json that fall within its constraints.

Verification steps

1. Run composer validate --strict to confirm that composer.json and composer.lock are present and consistent.
2. After restoring vendor, execute composer install --dry-run. If no packages are listed as "install", "update" or "remove", the vendor matches the lock.
3. Compare the installed versions with the lock: composer show --lock and diff the output against composer show to spot mismatches.
4. In a staging environment, run composer audit before committing any security‑related updates to verify that the candidate versions are safe.

Balancing stability and security

Update dependencies intentionally in a CI pipeline (e.g., composer update on a dedicated branch), review the resulting lock file, run tests, and then commit the new composer.lock. This allows security patches while keeping the exact versions used in production.

Missing diagnostic

Is the project a library that other teams consume, which might let them resolve their own constraints? Your answer determines whether the lock should be committed to VCS or kept out to allow downstream upgrades.