Composer ломается не там, где пакет плохой, а где у проекта нет правил
В большинстве PHP-проектов Composer используют как «установщик зависимостей», хотя он ещё и контракт на сборку. Если не зафиксировать его на старте, потом ловите сюрпризы: у одного разработчика всё поднимается, у другого падает автозагрузка, у третьего внезапно уезжает транзитивная зависимость.
Проверяйте базу:
— lock-файл должен коммититься, иначе вы не собираете тот же набор пакетов;
— версии в composer.json лучше ограничивать осмысленно, а не маской «на всё подряд»;
— автoload надо держать чистым: лишние namespace и дубли имен ломают предсказуемость;
— scripts и plugins стоит ревьюить так же, как обычный PHP-код.
Есть наблюдение которое стоит проверить: большинство «проблем Composer» на деле начинаются с мусора в vendor и неявных обновлений. Помогает простое правило — не править vendor руками, обновлять зависимости отдельной командой, а потом прогонять тесты и проверку автозагрузки. Если проект большой, полезно ещё разделить prod и dev-зависимости без самодеятельности в deployment-скриптах.
Когда Composer настроен как дисциплина, а не как магия, сборка становится повторяемой, а инцидентов на деплое заметно меньше.
Laravel & PHP Deep — фреймворки и пакеты
@laravel_php_deep
Composer ломается не там, где пакет плохой, а где у проекта нет правил
Этот пост опубликован в Telegram-канале Laravel & PHP Deep — фреймворки и пакеты. Подписаться можно по ссылке: @laravel_php_deep.