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

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

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

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

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

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

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