В этой короткой заметке я бы хотел поделиться с вами решением довольно популярной проблемы - resolve git conflicts in composer.lock.

Представьте себе ситуацию, когда вы в команде разрабатываете php проект. Для своей задачи вы создаете git branch feature/task1 и пишете в ней весь код по задаче, подключая зависимости через composer. В таком случае, также обновится и файл composer.lock, который хранит в себе полное дерево зависимостей с конкретными ссылками на коммиты зависимостей в репозиториях. Также для простоты, там прописывается content_hash, который вычисляется при добавлении/обновлении/удалении зависимости в проекте.

Вы завершили выполнение задачи и когда захотели слить ее в master через Pull Request, то обнаружили конфликты в файле composer.lock и composer.json. Кто-то из вашей команды уже слил в master свою задачу, где также менял эти файлы.

Так как эти файлы текстовые, то git практически в автоматическом режиме может слить эти файлы, но тогда в composer.lock поле content_hash будет неправильным.

Чтобы решить эту проблему, некоторые разработчики, принимают все изменения из master, выполняли composer install и потом доставляют зависимости ( composer require), которые нужны были им для решения своей задачи. Но с появлением Symfony Flex Recipes, если сделать так, то у вас удаляться все конфиги новых пакетов, поэтому такое решение не удобное, и не логичное.

А если лить изменения и свои и сторонние, а потом выполнить composer update, то хэш пересчитается, но совместно с этим обновятся все библиотеки в проекте. Я бы так точно делать не стал.

Решение

composer update --lock

Эта команда пересчитает composer.lock файл без обновления зависимостей.

Refresh lock file instead of updating? · Issue #754 · composer/composer
My peers & I are constantly getting the following warnings from Composer: BC warning: your lock file appears to be of an older format than this composer version, it is recommended to run compos...