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

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

Если зависимость «вдруг» не ставится, проблема часто не в репозитории, а в окружении. Composer чувствителен к версии PHP, правам на файловой системе, памяти и к тому, как настроен autoload.
Сначала проверяйте базу: запускается ли нужный PHP из CLI, совпадает ли он с тем, что использует проект, и не подменяется ли бинарник через alias или shell wrapper.

Дальше смотрите на <code>composer.json</code> и lock-файл. Частая ошибка — править зависимости вручную и не обновлять <code>composer.lock</code>. В итоге у команды разные наборы пакетов, а баг выглядит как «у меня работает». Для командного проекта lock должен жить в репозитории, а <code>composer install</code> — быть стандартной командой на боевом и в CI.

Еще один узкий участок — автозагрузка. Если класс не находится, проверьте namespace, PSR-4 mapping и регистр файловых имен. На Linux это всплывает особенно быстро: локально всё «норм», а на сервере путь уже не совпал. После правок не забывайте <code>dump-autoload</code>, если структура классов менялась.

И отдельно — плагины и скрипты Composer. Они удобны, но могут скрыть побочные эффекты: миграции, очистку кэша, генерацию файлов. Если установка стала нестабильной, временно отключайте лишние script hooks и ищите, на каком шаге всё падает.

<b>Надежный Composer — это не магия, а дисциплина: одинаковый PHP, чистый lock, корректный autoload и минимум сюрпризов в scripts.</b>