Composer является стандартом де-факто для управления зависимостями в PHP. Он прост, эффективен и уже стал вездесущ.

Каждый знает, что при использовании Composer вы просто создаёте файл composer.json со списком зависимостей и их версий, а после запускаете composer install и всё готово.

Потом вы коммитите composer.json в ваш проект и каждый разработчик вашей команды может легко установить все небходимые зависимости запустив composer install.

Конечно мы знаем и про composer update, которая обновит установленные пакеты до последний версии (опираясь на указанные версии в composer.json).

Это действительно просто. Но как насчёт файла composer.lock, который генерируется в корне проекта? Зачем ? И что нам с ним делать ?

А действительно ли вы знаете где находится .lock файл ?

Некоторое время назад я узнал, что проект OpenCFP не хранит файл composer.lock в репозитории. "Ну и что?!" - скажете вы, - “просто запускаем composer install и всё отлично. У нас установятся те же зависимости, верно?”

Нет. Не верно.

Предназначение .lock файла - записать в него непосредственно те версии, которые были установлены и под которые велась разработка и тестирование, чтобы в дальнейшем можно было их переустановить. Это означает, что если у вас в composer.json указана версия 1.*, а ваш коллега запустил composer update, которая установила 1.2.4 и закоммитил файл composer.lock, то вы, запустив composer install, получите ту же 1.2.4, даже если 1.3.0 уже вышла. Это позволяет быть уверенным, что каждый, кто работает над вашим проектом будет иметь абсолютно одинаковые версии пакетов.

Теперь вы может быть подумали: при надлежащем семантическом версионировании версия 1.3.0 (или даже 1.2.5) должна быть обратно совместимой, т.к. всё ещё удовлетворяет указанному значению 1.* и major-ная версия не изменилась. В чём же заключается сакраментальная мысль ?

Что ж, пока вы не делаете код-ревью каждой новой версии используемых вами зависимостей, и их зависимостей, и зависимостей зависимостей... и т.д. и т.п., то остаётся высокая вероятность того, что какой-нибудь закравшийся баг поломает ваше приложение. В конце концов, все мы люди.

Ещё достаточно рапространённая практика для проектов ставить в зависимостях ссылку на dev-master, что позволяет всегда иметь самые последние изменения. Это означает, что при каждом запуске composer install, но без сохранённого lock файла, composer будет устанавливать самый последний код библиотек, который будет напрямую с-pull-ен из их репозиториев.

Опять же, это проблема, если вы беспокоитесь о взломе вашего кода. И  это одна из причин почему важно представлять Composer сфокусированным вокруг файла composer.lock. Это некое устройство безопасности и должно использоваться как таковое.

Install или Update?

Часто разработчики теряются когда они должны использовать install update. Как только вы начнёте думать об этом как о действиях с lock файлом, нежели как о зависимостях, всё встанет на свои места и будет более понятным.

Команда composer install делает следующее:

• Проверяет существует ли composer.lock
• если нет, резолвит зависимости и создаёт его
• если composer.lock существует, устанавливает версии, указанные в нём

Команда composer update:

• Проверяет composer.json
• Определяет последние версии на основе указанных в этом файле
• Устанавливает последние версии
• Обновляет composer.lock в соответствии с установленными

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

Есть одно исключение из правила. В том случае, если вы устанавливаете что-то вроеде Zend Framework 2 Skeleton App, зависимости должны быть обновлены как только вы установили подобный каркас. Это потому, что Skeleton App является эдаким мета-приложением (карксом-примером). Соответственно в этом случае вы захотите "подтянуть" последние версии зависимостей, которые станут отправной точкой для начала разработки. Поэтому composer.lock не коммитится в репозитории подобных мета-приложений.

Выкладка (deploy)

При deploy-е приложения, имея composer.lock в вашем репозитории, вы должны использовать команду composer install. Так мы будем уверены, что на production сервере используются те же самые версии пакетов, как и при разработке. А также это значит, что Composer-у не требуется выполнять разрешение зависимостей и искать требуемые версии, что увеличивает скорость разворачивания.

Наличие файла composer.lock также обеспечивает консистентность между кластерами серверов, если вы запускаете Composer отдельно на каждой машине. Это позволяет вам развернуть новые ноды(машины) неделями или месяцами позже, не беспокоясь о несовпадении версий зависимостей.

Заключение

Как вы видите, это всё о .lock файле. Если вы задумались какую команду использовать composer install или composer update, пусть .lock файл направит вас. Если вы ассоциируете эти команды с тем, как они работают с содержимым .lock файла (а не с зависимостями) вы никогда не ошибётесь.

В общем, если вы задумаетесь коммитить ли файл composer.lock в систему контроля версий, ответ: ДА.