Composer давно и, видимо, надолго занял твердое место в качестве менеджера пакетов для PHP. Он довольно прост, эффективен и встречается повсеместно.
Известно, что достаточно создать файл composer.json, в котором просто перечислить список необходимых пакетов и их версий и запустить composer install.
Потом просто сохраняете вашу версию в систему контроля версий, и любой человек работающий с вами в команде просто выполняет composer install и получает проект со всеми установленными зависимостями.
Чтобы обновить все зависимости вашего проекта достаточно выполнить composer update. Выглядит довольно просто. Но, тем не менее, существует файл composer.lock, который генерируется в корне вашего проекта. Для чего он? Что с ним делать?
А знаете ли вы где находится ваш lock файл?
Несколько недель назад в своем твитере я сделал заметку о том, что в проекте OpenCFP отсутствует composer.lock файл. Ну и что такого, могли бы вы сказать, достаточно запустить composer install и он там появится. Ведь вы установите те же самые пакеты, не так ли?”. А вот и нет.
Вся суть этого файла в том, что в нём хранятся точные версии установленных пакетов, что требуется для их переустановки. То есть допустим, у вас установлена версия пакета 1.*, ваш коллега выполняет composer update и получает версию 1.2.4, а файл composer.lock отправляет в систему контроля версий. Таким образом вы тоже получите версию 1.2.4, даже если доступна 1.3.0. То есть все участники разработки работают с одними и теми же версиями пакетов.
Хорошо, следующий вопрос, который может у вас возникнуть, по идее все новые версии пакетов должны быть совместимы с более старыми, в чем же загвоздка?
Конечно, если вы проводите полное рецензирование своего кода от зависимости к зависимости, то может вы и избежите проблем, но, скорее всего, шанс, что небольшой баг все таки закрадется, довольно велик. Человеческий фактор никто не отменял.
Довольно часто в composer.json в качестве версии указывается dev-master, таким образом вы получаете самую последнюю версию пакета. Таким образом если что-то новое было добавлено в пакет со времени последнего обновления проекта, вы получите этот код себе если не используете lock файл.
Опять, это может вызвать лишние поломки в коде. Поэтому строить свой проект стоит именно на основе файла composer.lock. В конце концов composer это инструмент помогающий отгородить вас от лишних проблем в коде и с этой точки зрения он и должен быть использован.
Install или Update?
Часто люди задают вопрос, как же правильнее поступать, обновлять или устанавливать проект. Как только вы поставите в центр внимания composer.lock файл, а не список зависимостей, картина станет яснее.
Запуск composer install сделает следующее:
- Проверит существует ли composer.lock файл
- Если его нет, то выполнит
composer updateи создаст его - Если файл уже существует, то установит указанные версии пакетов из lock файла
Запуск composer update выполнит:
- Проверит
composer.json - Составит список пакетов, которые следует обновить, основываясь на указанные версии пакетов
- Установит последние обновления
- Обновит файл composer.lock
В любом случае после каждой из команд следует отправить composer.lock в файл в систему контроля версий, чтобы все ваши коллеги также использовали нужные версии.
Но существует исключение из правил. При использовании, например, Zend Framework 2 Skeleton App, зависимости должны обновляться при установке, так как Skeleton App это мета приложение. Поэтому вам необходимы последние обновления перед началом разработки. Но файл composer.lock не сохраняется в систему контроля версий.
Развертывание проекта
При наличии composer.lock вы должны запускать composer install при развертывании проекта. Таким образом вы получаете одинаковые версии пакетов на рабочем сервере и на машине разработчика. Также composer не требует проверять все зависимости и их версии, что повышает производительность проекта.
Также при использовании composer.lock вы получаете стабильный набор пакетов и их версий при использовании кластеров. Вы можете легко обновлять проект на недели или месяцы позднее, чем обновились версии пакетов, и вам не придется задумываться о возможных конфликтах версий.
Заключение
Как вы сами видите, что файл composer.lock несет на себе довольно большую ответственность. И если у вас возникает вопрос обновлять вам или устанавливать пакеты, то именно этот файл должен помочь вам найти ответ. Если вы правильно свяжете эти команды с тем, что они делают с файлом composer.lock(а не с зависимостями), то вы не ошибётесь.
В общем, если у вас есть сомнения отправлять ли composer.lock в систему контроля версий, то ответ — ДА.