Composer ломает проект не в коде, а в способе подключения пакетов

Composer ломает проект не в коде, а в способе подключения пакетов

Плохая привычка — ставить всё через «самый короткий путь» и надеяться, что автозагрузка сама разрулит. В Composer важны три вещи: стабильные ограничения версий, предсказуемый lock-файл и понимание, кто именно тянет зависимость.

Проверьте базовый набор:
— прямые зависимости в require должны быть только у того, чем вы реально пользуетесь;
— dev-пакеты не должны попадать в боевой контейнер;
— обновление делайте через одно место, а не точечно правя десяток package;
— после изменений смотрите tree зависимостей, иначе конфликт всплывёт уже в проде.

Отдельная зона риска — скрипты post-install и post-update. Удобно, пока они не начинают выполнять магию при каждом развёртывании. Любой пакет с автокомандами нужно читать как часть инфраструктуры, а не как безобидную библиотеку 📦

Если проект живёт долго, держите Composer как инструмент контроля, а не как кнопку «обновить всё». Чем чище дерево зависимостей и чем реже ручные правки lock-файла, тем меньше сюрпризов в деплое.