Enterprise Drupal / March 2026
`composer.lock` is not an administrative by-product
With dependency problems, the relevant question was not simply whether a package could be installed. The same resolved graph had to be reproducible across development, CI and production.
Situation
In legacy PHP projects, it is tempting to solve a local dependency conflict with a targeted update and move on. That works until another environment derives a different version combination from the same `composer.json`. Several March investigations made it clear that lock-file quality is directly connected to production risk.
Approach
I treated dependency changes like release artifacts. I reviewed what actually changed in the lock file, why a transitive version moved and whether the platform constraints matched the target environment. Instead of saying 'Composer solved it', I checked whether the resolution was intentional and whether CI would install the same graph we had tested locally.
Outcome
Package-update diffs became smaller and easier to explain. When an upgrade wanted to move additional dependencies, that became visible during review instead of deployment. The same reproducibility principle later became fundamental to immutable release work in KampányMűvek.