Почему так важен файл composer.lock?
До недавнего времени я не понимал назначение файла composer.lock и почему его нужно добавлять в систему контроля версий. Ведь если существует composer.json, который содержит все зависимости и их версии, то зачем нужен composer.lock? В добавок, из-за этого файла часто приходиться разбираться с конфликтами каждый раз, когда кто-нибудь делает composer update, а это тот еще головняк.
Как оказалось, я действительно не понимал роль данного файла и не использовал команды composer правильно.
Итак, представим, что мы создаем проект в котором есть файл composer.json со следующим содержимым:
Я предполагаю, что вы знакомы с композером и понимаете, что будут установлены:
- bar-package-A версии 0.1.0
- bar-package-B версии 0.1.2
- bar-package-C используя последнюю минорную версию 0.1
Сейчас в нашем проекте нет файла composer.lock, но когда мы запустим composer install, композер создаст его и начнет устанавливать зависимости, используя для этого файл composer.json. На первый взгляд, все эти длинные непонятные хэши и числа в composer.lock сбивают с толку. Однако, если копнуть глубже, все окажется довольно просто.
Так что же такое composer.lock?
Это просто файл, который сообщает композеру версию каждого пакета, который был установлен.
Мы видим, что bar-package-C установлен версии 0.1.6. Намного точнее, нежели чем указано в файле composer.json, где указана только версия 0.1.*
Хорошо, но все равно непонятно, почему это так важно?
Давайте представим следующие ситуации:
Ситуация 1: в команде новый разработчик.
Представьте, что к вашей команде присоединился новый разработчик и вы дали ему инструкции по
клонированию репозитория вашего проекта (который не содержит файл composer.lock в системе контроля версий).
После того, как он склонирует проект, следующим логическим шагом будет установка всех зависимостей.
После установки, разработчик пытается запустить тесты... Но вот незадача, тесты не проходят на его компьютере, хотя у вас или у любого другого члена вашей команды все работает как надо. Вы не понимаете почему так происходит, начинаете сомневаться в новом сотруднике, предполагая, что он делает что-то не так.
А произошло это потому, что после установки зависимостей вашим новым коллегой пакет bar-package-C получил версию 0.1.7, в то время как ваши тесты хорошо работали для версии 0.1.6. Почему так произошло? Потому, что в composer.json указана версия 0.1.* для пакета bar-package-C, но на днях для него вышел новый релиз с версией 0.1.7, которую вы не тестировали.
Если бы файл composer.lock был добавлен в VCS, композер бы использовал более точные иструкции, нежели чем в composer.json и установил бы пакет версии 0.1.6, а вы сэкономили бы много времени для вашего нового сотрудника.
Ситуация 2: деплой с использованием git
На этот раз представьте, что у вас организован какой-нибудь сценарий автоматического развертывания кода, который использует содержимое вашего VCS репозитория, устанавливает зависимости и заливает все в продакшн. Вы снова не добавили composer.lock в ваш репозиторий и после деплоя... ваше приложение не работает.
И опять это случилось потому, что при развертывании вашего приложения на проде композер использовал файл composer.json и установил версию 0.1.7 пакета bac-package-C, вместо версии 0.1.6. Получается, что версия 0.1.7 содержит в себе баг.
Если бы вы добавили composer.lock в ваш репозиторий, композер знал бы, что нужно использовать версию 0.1.6.
Подведем итог!
composer.lock необходимо включать в систему контроля версий, если вы хотите, чтобы версии ваших зависимостей синхронизировались между разработчиками вашего приложения.
Я надеюсь, что этот небольшой материал пролил немного света на composer.lock, для тех из вас, кто не понимал как его использовать.
Списибо за внимание!
Блок комментариев