Composer ломается не в install, а в дисциплине зависимостей
В проектах на PHP Composer часто воспринимают как «поставил и забыл». Потом начинается ад: один пакет тянет лишнее, другой требует старый контракт, третий конфликтует по расширениям. Лечится не магией, а привычкой читать composer.json как спецификацию, а не как мусорку для require.
Три правила, которые экономят часы:
— фиксируй версии там, где нужен повторяемый деплой, а не «любая подходящая»;
— отделяй dev-зависимости от runtime, иначе тестовый пакет легко уедет в прод;
— перед merge всегда смотри дерево зависимостей, а не только успешный install.
Отдельно проверь автозагрузку: PSR-4 с неправильным namespace и лишние classmap-файлы дают тихие баги, которые выглядят как «Laravel чудит». Ещё один частый провал — обновление пакета без проверки его transitive-зависимостей: конфликт может сидеть не в самом пакете, а глубже в цепочке.
Если Composer в проекте начинает «сыпаться», сначала чинят структуру зависимостей, потом уже код. Это тот случай, когда аккуратный composer.json дешевле любого срочного hotfix.
Laravel & PHP Deep — фреймворки и пакеты
@laravel_php_deep
Composer ломается не в install, а в дисциплине зависимостей
Этот пост опубликован в Telegram-канале Laravel & PHP Deep — фреймворки и пакеты. Подписаться можно по ссылке: @laravel_php_deep.