<b>Composer ломает проект не сборкой, а дисциплиной зависимостей</b>

<b>Composer ломает проект не сборкой, а дисциплиной зависимостей</b>

В PHP-проекте Composer — это не «поставить пакет», а зафиксировать состояние дерева. Если команда живёт на голом install без ревизии lock-файла, проблемы копятся тихо: у одного окружения код проходит, у другого уже нет.

Три вещи, которые стоит проверять всегда:
— composer.json: нет ли там лишних широких диапазонов версий
— composer.lock: закоммичен ли он и совпадает ли с реальным набором пакетов
— autoload: не тащите ли вы классы, которые давно переехали или дублируются

Ещё одна типовая ошибка — обновлять пакет в одиночку и не смотреть на соседей по дереву. В Composer конфликт часто сидит не в нужной библиотеке, а в её зависимости. Поэтому перед merge полезно прогнать install на чистом окружении и посмотреть, что именно меняется в lock-файле.

Если проект растёт, заведите правило: любое изменение зависимостей проходит через diff lock-файла и проверку автозагрузки. Это дешевле, чем потом искать «магическую» поломку в production.