<b>Composer ломается не в install, а в том, как вы описали зависимости</b>

<b>Composer ломается не в install, а в том, как вы описали зависимости</b>

Composer — это не просто менеджер пакетов, а контракт между вашим проектом и внешним миром. Если контракт кривой, проблем не избежать: от «почему у меня локально работает» до странных конфликтов в CI.

Вот что проверяют первыми:
— <code>require</code> и <code>require-dev</code> не смешивают боевые и тестовые зависимости.
— Версии задают осознанно: слишком широкий диапазон тянет неожиданные апгрейды, слишком узкий ломает обновления.
— <code>composer.lock</code> коммитят в приложение, но не делают из него мусорку для ручных правок.
— <code>autoload</code> должен быть чистым: неправильные namespace-ы и PSR-4 потом выглядят как «магия».

Отдельная зона риска — post-install скрипты и плагины. Если в проекте есть команда, которая меняет состояние системы, проверьте, переживает ли она чистую установку, пустой кеш и запуск в CI без интерактива.

Ещё один частый провал — игнорировать <code>composer why</code> и <code>composer why-not</code>. Когда пакет не ставится, причина почти всегда не в самом пакете, а в цепочке зависимостей выше. Эти команды экономят часы гаданий.

Если хотите меньше сюрпризов, держите правило простым: сначала читаем дерево зависимостей, потом обновляем. Не наоборот.