Enterprise Drupal / 2026. március
A composer.lock nem adminisztrációs melléktermék
Egy dependency-problémánál nem az volt a kérdés, hogy „felmegy-e a csomag”, hanem hogy ugyanaz a dependency graph reprodukálható-e fejlesztői, CI és production környezetben.
A helyzet
Legacy PHP-projektnél gyakori kísértés egy lokális dependency konfliktust gyorsan feloldani egy célzott update-tel, majd továbbmenni. Ez addig működik, amíg egy másik környezet ugyanabból a composer.json-ból más verziókombinációt rak össze. Márciusban több hibakeresésnél látszott, hogy a lock fájl minősége közvetlenül production-kockázat.
A megoldási út
A dependency-változásokat úgy kezeltem, mint release-artifactot. Megnéztem, mi változik ténylegesen a lockban, miért kerül be egy transitív verzió, és a platform constraint megfelel-e a célkörnyezetnek. A „Composer megoldotta” mondat helyett azt kerestem, hogy a feloldás szándékos-e, és a CI ugyanazt telepíti-e, amit lokálisan teszteltünk.
Mi lett belőle
A csomagfrissítések diffje kisebb és magyarázhatóbb lett. Amikor egy upgrade további csomagokat akart megmozdítani, az már korán látszott, nem a deployment közben. A reproducibility később a KampányMűvek immutable release gondolkodásában is ugyanilyen alapelvvé vált.