Composer ломает проект не пакетом, а привычкой тащить всё в root без правил

Composer ломает проект не пакетом, а привычкой тащить всё в root без правил

В PHP-проекте Composer — это не «установщик библиотек», а источник порядка. Если в корне лежат лишние пакеты, плавает автозагрузка и нет контроля над версиями, проблема почти всегда не в самом Composer, а в дисциплине команды.

Проверь базу:
— composer.json содержит только нужные require и scripts
— composer.lock закоммичен, если проект не библиотека
— autoload не разрастается в свалку из псевдо-namespace’ов
— post-install-cmd и post-update-cmd не прячут важную логику
— dev-зависимости не тянут прод-код через боковую дверь

Отдельный риск — неявные обновления. Если пакет ставится «по символам» вроде ^ без понимания семантики, одна мелкая правка в дереве зависимостей может поменять поведение соседнего модуля. Для продакшена это лечится двумя вещами: фиксировать lock-файл и регулярно прогонять composer update в отдельной ветке с тестами, а не в боевом коммите.

Есть ещё тихая поломка: scripts, которые делают слишком много. Composer должен собирать проект, а не заменять деплой-пайплайн. Если там миграции, очистка кэшей и вызовы внешних сервисов, любая установка становится лотереей.

Держите Composer как инфраструктурный слой: минимум магии, максимум предсказуемости. Тогда зависимости обновляются без сюрпризов, а не «как-нибудь потом починим».