Ошибки после обновления Composer-зависимостей: что проверить

После composer update проект может сломаться неожиданно: локально всё работало, а на сервере появляется fatal error, несовместимость PHP, Class not found, конфликт пакетов или изменившееся поведение библиотеки. Основная причина — composer update обновляет зависимости в рамках разрешённых версий, и иногда подтягивает больше изменений, чем ожидалось.

Для production чаще безопаснее использовать composer install по зафиксированному composer.lock, а update выполнять осознанно на тестовой копии.

composer update и composer install

composer update пересчитывает версии пакетов и обновляет composer.lock. composer install устанавливает версии, уже записанные в lock-файле.

composer update
composer install --no-dev --prefer-dist --optimize-autoloader

На сервере обычно нужен install. Если на production выполнить update, можно получить версии, которые никто не проверял.

Проверить composer.lock

Если после деплоя появились ошибки, нужно посмотреть, изменился ли composer.lock. Именно он фиксирует конкретные версии пакетов.

git diff composer.lock
git log -- composer.lock

Если lock изменился случайно, стоит понять, какие пакеты обновились и почему.

composer show -D
composer outdated

PHP-версия

Пакет может требовать более новую PHP-версию, чем стоит на сервере. Или наоборот: новая PHP-версия больше не поддерживается старой библиотекой.

composer check-platform-reqs

Эту команду полезно выполнять в том окружении, где проект реально запускается. Иначе локальная машина может показать одно, а сервер — другое.

Конфликт версий

Если Composer не может подобрать зависимости, он обычно пишет, какие constraints конфликтуют. Не нужно сразу удалять composer.lock или vendor наугад. Сначала стоит прочитать конфликт.

composer why package/name
composer why-not package/name 2.0.0

Команды why и why-not помогают понять, какой пакет держит старую версию или мешает обновлению.

Autoload

После изменения классов или namespace может понадобиться пересобрать autoload.

composer dump-autoload -o

Но если проблема в несовместимой версии пакета, dump-autoload её не исправит. Он помогает только с автозагрузкой.

Удалять vendor осторожно

Удаление vendor иногда помогает избавиться от повреждённой установки, но не должно быть первым шагом. Если composer.lock не зафиксирован или выполняется update, после удаления vendor можно получить другой набор версий.

rm -rf vendor
composer install --no-dev --prefer-dist --optimize-autoloader

Перед такой операцией нужно убедиться, что composer.lock актуален и закоммичен.

Major updates

Если в composer.json указано слишком свободное ограничение, можно случайно подтянуть major-версию с несовместимыми изменениями.

"package/name": "*"

Так лучше не делать. Безопаснее указывать понятные constraints:

"package/name": "^1.8"

Даже minor update может изменить поведение, поэтому важные пакеты нужно обновлять на тестовой копии.

План отката

Если после обновления всё сломалось, самый быстрый откат — вернуть composer.json и composer.lock к предыдущему состоянию и выполнить install.

git checkout HEAD~1 -- composer.json composer.lock
composer install --no-dev --prefer-dist --optimize-autoloader

Конкретная команда зависит от git-истории. Главное — откатывать lock-файл вместе с composer.json.

Чек-лист диагностики

1. Понять, выполнялся composer update или install.
2. Проверить изменения composer.lock.
3. Проверить PHP-версию и platform requirements.
4. Прочитать текст конфликта Composer.
5. Использовать composer why и why-not.
6. Пересобрать autoload, если менялись классы.
7. Не удалять vendor без актуального lock-файла.
8. Откатывать composer.json и composer.lock вместе.

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