Когда composer install падает на сервере, деплой останавливается: сайт не обновляется, автозагрузка не собирается, а новая версия кода остается в подвешенном состоянии.
Такая ошибка особенно неприятна на рабочем проекте, где обновление нужно сделать быстро и без простоя. Важно не удалять зависимости вслепую, а понять, почему Composer не может собрать проект.
Коротко: нужно сверить версию PHP, расширения, composer.lock, память, права и доступ к пакетам.Почему это ломается
Composer падает из-за несовместимой версии PHP, отсутствующих расширений, малого memory_limit, битого vendor, конфликтов composer.lock, закрытого Git-репозитория, неверных прав или запуска не тем PHP-бинарником.
Что проверяю в первую очередь
- какой PHP использует Composer в CLI
- что написано в тексте ошибки Composer
- совпадают ли composer.json и composer.lock
- хватает ли памяти и расширений PHP
- доступны ли приватные пакеты и Git-репозитории
Как я это чиню
Я не начинаю с удаления composer.lock. Сначала фиксирую ошибку, проверяю окружение и запускаю Composer тем PHP, который нужен проекту.
- подбираю правильный PHP CLI для проекта
- устанавливаю недостающие расширения
- исправляю права на vendor и cache
- разбираю конфликт зависимостей без случайного обновления всего проекта
- проверяю autoload после успешной установки
Что подготовить перед обращением
- текст ошибки composer install
- доступ к серверу
- версию PHP проекта
- composer.json и composer.lock
- описание последнего обновления
Как выглядит нормальный результат
После исправления composer install должен стабильно завершаться на сервере, а проект должен запускаться с теми зависимостями, которые ожидает код.
Чего лучше не делать
Не запускайте composer update на продакшене без понимания последствий. Он может обновить больше пакетов, чем нужно, и создать новые ошибки.
Вопросы и ответы
Почему локально работает, а на сервере нет?
Обычно отличаются PHP, расширения, права, память или доступ к приватным пакетам.
Можно ли просто скопировать vendor с локального компьютера?
Иногда можно как временную меру, но лучше привести серверное окружение в рабочее состояние.
Что делать с memory exhausted?
Проверить memory_limit, версию Composer и реальный объем зависимостей. Часто помогает запуск с правильным лимитом.
Нужно ли удалять composer.lock?
Нет, composer.lock нужен для повторяемой установки. Удалять его стоит только осознанно.
Нужна похожая задача?
Напишите в Telegram @rabotator_support или оставьте заявку на сайте. Коротко опишите проблему, приложите ссылку, скриншот или лог ошибки, и я подскажу, с чего безопасно начать исправление.
Итог
Composer install чинится через окружение и зависимости: PHP, расширения, память, lock-файл и права должны соответствовать проекту.