Ответ
Разница заключается в том, какой файл (composer.json или composer.lock) является источником истины для определения устанавливаемых версий пакетов.
composer install
- Основная задача: Установить зависимости, точно соответствующие версиям, зафиксированным в
composer.lock. - Как работает:
- Проверяет наличие файла
composer.lock. - Если файл есть, устанавливает все пакеты в версиях, указанных в нем. Это гарантирует, что у всех разработчиков и на всех окружениях (dev, staging, production) будут идентичные версии зависимостей.
- Если файла
composer.lockнет (например, проект только что склонирован), он ведет себя какcomposer update— читаетcomposer.json, устанавливает последние подходящие версии и создает новыйcomposer.lock.
- Проверяет наличие файла
- Когда использовать: Всегда при развертывании проекта на новое окружение (продакшен, CI/CD-пайплайн, новая машина разработчика). Это команда для воспроизведения известного рабочего состояния.
composer update
- Основная задача: Обновить зависимости до последних версий, разрешенных правилами в
composer.json, и записать новые версии вcomposer.lock. - Как работает:
- Игнорирует текущий
composer.lock. - Читает
composer.jsonи для каждого пакета находит самую новую версию, удовлетворяющую указанному ограничению (например,^8.0). - Устанавливает эти новые версии и генерирует обновленный файл
composer.lock.
- Игнорирует текущий
- Когда использовать: В процессе разработки, когда вы хотите получить обновления пакетов (новые фичи, исправления безопасности).
Практическое правило и примеры
Правило: composer.lock должен коммититься в репозиторий. На продакшене всегда выполняется composer install --no-dev.
Пример рабочего процесса:
# 1. Клонируем проект (composer.lock уже в репозитории)
git clone project.git
cd project
# 2. Воспроизводим точное состояние зависимостей (для разработки)
composer install
# 3. В процессе работы решили обновить пакет symfony/http-kernel до новой minor-версии
# Обновляем только его, чтобы минимизировать риски
composer update symfony/http-kernel
# 4. Проверяем, что все работает, коммитим ИЗМЕНЕННЫЙ composer.lock
git add composer.lock
git commit -m "Update symfony/http-kernel to v6.3.10"
# 5. На сервере (CI/CD) снова выполняется install для развертывания
composer install --no-dev --optimize-autoloaderКлючевое отличие в одном предложении: install восстанавливает состояние из lock-файла, update изменяет lock-файл, обновляя зависимости.
Ответ 18+ 🔞
А, ну это же классика, ебать мои старые костыли! Сейчас объясню на пальцах, без этой вашей заумщины.
Представь, что composer.json — это твой список покупок в стиле «купи пива, какого-нибудь». А composer.lock — это уже пробитый на кассе чек, где чётко написано «Пиво "Балтика 9", 2 бутылки». Понимаешь разницу?
composer install — это когда ты пришёл домой и просто достаёшь из пакета то, что уже куплено по чеку. Он смотрит в composer.lock и ставит всё точно так же, до последней запятой в версии. Если чека нет — он сначала сходит в магазин, как update, и чек создаст. Эта команда для того, чтобы все в команде и на сервере имели абсолютно одинаковые версии пакетов. Без сюрпризов. На продакшене — только она, и точка.
composer update — это когда ты берёшь свой старый список, идёшь в магазин и говоришь: «Дайте мне самое свежее пиво, какое есть, но только чтоб "Балтика"». Он игнорирует твой старый чек, лезет в репозитории, ищет самые новые версии, которые подходят под условия в composer.json (типа ^8.0), и формирует новый чек. После этого у тебя могут появиться новые версии пакетов, а могут и хуй с горой сломаться, если что-то где-то не совместимо.
Простое правило, которое спасёт тебя от пиздеца:
composer.lockвсегда в гите коммитишь. Это святое. Кто не коммитит — тот полупидор.- На своей машине, в процессе разработки, если хочешь обновить зависимости — делаешь
composer update. Но желательно не все сразу, а конкретный пакет:composer update symfony/http-kernel. Потом тестишь, что ничего не разъебало, и коммитишь обновлённыйcomposer.lock. - На сервере, в CI/CD, при развёртывании — ВСЕГДА
composer install --no-dev. Никакихupdate! Сервер должен взять чек и воспроизвести точь-в-точь то, что было у тебя на машине. Доверия к окружению — ноль ебать.
Вот и вся магия. install — для стабильности и развёртывания, update — для обновлений в процессе разработки. Запомни это, и волнение ебать по поводу «а почему у меня работает, а на сервере нет» отпадёт само собой.
