<b>Composer ломается не из-за пакетов, а из-за порядка действий в проекте</b>
В реальной работе Composer чаще всего подводит не «магией зависимостей», а грязным деревом проекта. Проверьте базу: один composer.json на корень, lock-файл в репозитории, vendor не коммитится, автозагрузка пересобирается после любых изменений namespace.
Три вещи, которые стоит держать как правило:
— не смешивать ручное правление dependency tree с обновлением через composer require;
— не править vendor руками, если нужен патч — используйте fork или patch-слой;
— не запускать install там, где нужен update: это разные сценарии, и они дают разный результат.
Если ловите конфликт, смотрите не на первое сообщение, а на цепочку. Часто проблема в скрытой зависимости пакета, в платформенных требованиях PHP/ext или в том, что один пакет зафиксировал слишком узкий диапазон версий. Для диагностики полезны composer why, composer why-not и validate — они быстрее, чем гадание по stack trace. 🧩
Хорошая привычка простая: сначала стабилизируйте lock-файл, потом уже обновляйте пакеты. Тогда Composer перестаёт быть источником сюрпризов и становится обычным инструментом сборки.
Laravel & PHP Deep — фреймворки и пакеты
@laravel_php_deep
<b>Composer ломается не из-за пакетов, а из-за порядка действий в проекте</b>
Этот пост опубликован в Telegram-канале Laravel & PHP Deep — фреймворки и пакеты. Подписаться можно по ссылке: @laravel_php_deep.