<b>Composer ломает проект не в vendor, а в привычках команды</b>

<b>Composer ломает проект не в vendor, а в привычках команды</b>

За неделю в репах: половина «странных» багов после установки пакетов — это не пакет, а дисциплина вокруг Composer.

• Не коммитьте vendor, если у вас не зафиксирован особый сценарий деплоя.
• Всегда храните composer.lock в репозитории: без него вы не воспроизводите сборку.
• Не правьте зависимости руками в JSON, если можно использовать require/update/remove и сразу проверять конфликт.

Ещё три места, где обычно прячется боль: autoload, scripts и платформенные требования. Если PSR-4 маппинг расходится с реальной структурой, классы «пропадают» только на части окружений. Скрипты удобны, пока в них не складывают всё подряд: лучше держать там тонкие команды, а бизнес-логику — в коде. platform.php и ext-список помогают поймать несовместимость до выката, а не после.

Полезная привычка: перед merge прогоняйте composer validate, composer install и проверку автозагрузки в чистом окружении. Если проект большой, отдельно фиксируйте набор пакетов для dev и production — так проще понять, откуда пришла поломка.

Composer не про «поставить пакет», а про воспроизводимость. Чем раньше команда это принимает, тем меньше сюрпризов на стенде и в проде.