Composer ломается не там, где пакет плохой, а где у проекта нет правил

Composer ломается не там, где пакет плохой, а где у проекта нет правил

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

Проверяйте базу:
— lock-файл должен коммититься, иначе вы не собираете тот же набор пакетов;
— версии в composer.json лучше ограничивать осмысленно, а не маской «на всё подряд»;
— автoload надо держать чистым: лишние namespace и дубли имен ломают предсказуемость;
— scripts и plugins стоит ревьюить так же, как обычный PHP-код.

Есть наблюдение которое стоит проверить: большинство «проблем Composer» на деле начинаются с мусора в vendor и неявных обновлений. Помогает простое правило — не править vendor руками, обновлять зависимости отдельной командой, а потом прогонять тесты и проверку автозагрузки. Если проект большой, полезно ещё разделить prod и dev-зависимости без самодеятельности в deployment-скриптах.

Когда Composer настроен как дисциплина, а не как магия, сборка становится повторяемой, а инцидентов на деплое заметно меньше.