Composer - все дело в lock файле

  • PHP
  • 15,637
  • 1
  • 3
  • 0
  • 2 года назад

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 в систему контроля версий, то ответ - ДА.

Комментарии

3
Матерна Сергей, 10 месяцев назад
1

Спасибо! Мечтаю чтобы все доки были в таком стиле. Очень информативно!