Должен быть композитор.блокировка должна быть привязана к контролю версий?

Для приложений/проектов: Определенно да.

В документации композитора говорится об этом (с акцентом):

Зафиксируйте составителя вашего приложения.блокировка (вместе с composer.json) в системе управления версиями.

Как сказал @meza: вы должны зафиксировать файл блокировки, чтобы вы и ваши сотрудники работали над одним и тем же набором версий и не допускали высказываний типа "Но это сработало на моем компьютере". ;-)

Для библиотек: Наверное, нет.

Примечания к документации композитора по этому вопросу:

Примечание: Для библиотек не обязательно рекомендуется фиксировать файл блокировки (...)

И состояния здесь:

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

Для библиотек я согласен с ответом @Josh Johnson.

После того, как я сделал это в обоих направлениях для нескольких проектов, моя позиция заключается в том, что composer.lock не следует фиксировать как часть проекта. Я знаю, что это проще сделать, но, пожалуйста, потерпите меня, пока я буду обосновывать это.

composer.lock это метаданные сборки, которые не являются частью проекта. Состояние зависимостей должно контролироваться с помощью того, как вы их версируете (вручную или в рамках автоматизированного процесса сборки), а не произвольно последним разработчиком, который обновит их и зафиксирует файл блокировки.

Если вас беспокоит изменение зависимостей между обновлениями composer, то у вас нет уверенности в вашей схеме управления версиями. Версии (1.0, 1.1, 1.2 и т.д.) Должны быть неизменяемыми, и вам следует избегать подстановочных знаков "dev-" и "X.*" за пределами начальной разработки функций.

Фиксация файла блокировки является регрессией для вашей системы управления зависимостями, поскольку версия зависимости теперь вернулась к определению неявности.

Кроме того, ваш проект никогда не нужно перестраивать или восстанавливать зависимости в каждой среде, особенно в prod. Ваш результат (tar, zip, phar, каталог и т. Д.) Должен быть неизменяемым и продвигаться в средах без изменения состояния.

Редактировать: Я знал, что это не будет популярным ответом, но если вы проголосуете против, не будете ли вы так любезны указать причину в комментариях, которая указывает на недостаток в ответе? Спасибо!

1. Вы не должны обновлять свои зависимости непосредственно от производства.
2. Вы должны контролировать версию своего файла composer.lock.
3. Вы не должны контролировать версии своих фактических зависимостей.

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

2. Вы должны контролировать версию своего файла composer.lock, потому что в нем хранится информация о ваших зависимостях и о зависимостях ваших зависимостей, которая позволит вам воспроизвести текущее состояние кода. Это важно, потому что все ваше тестирование и разработка были проведены против конкретный код. Не заботясь о фактической версии кода, который у вас есть, это похоже на загрузку изменений кода в ваше приложение, а не на их тестирование. Если вы обновляете версии своих зависимостей, это должно быть добровольным действием, и вы должны принять необходимые меры, чтобы убедиться, что все по-прежнему работает. Потеря одного или двух часов времени до возврата к предыдущей версии может стоить вам больших денег.

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

Это означает, что даже если вы укажете, что хотите использовать Laravel 4.1.31 в своем composer.json, Laravel в своем файле composer.json может иметь свои собственные зависимости, необходимые в качестве диспетчера событий Symfony: 2.*. С такой конфигурацией вы можете получить Laravel 4.1.31 с диспетчером событий Symfony 2.4.1, а у кого-то другого в вашей команде может быть Laravel 4.1.31 с диспетчером событий 2.6.5, все будет зависеть от того, когда вы в последний раз запускали установку composer.

Таким образом, наличие вашего файла composer.lock в системе версий сохранит точная версия этих зависимостей, поэтому, когда вы и ваш товарищ по команде устанавливаете composer (таким образом вы будете устанавливать свои зависимости на основе composer.lock), вы оба получите одинаковые версии.

Что, если вы хотите обновить информацию? Затем в вашей среде разработки запустите: composer update, это сгенерирует новый файл composer.lock (если есть что-то новое) и после того, как вы его протестируете, а также протестируете QA и регрессионный тест и прочее. Вы можете подтолкнуть его к тому, чтобы все остальные загрузите новый composer.lock, так как его безопасно обновлять.

3. Вы не должны контролировать версии своих фактических зависимостей, потому что это не имеет смысла. С помощью composer.lock вы можете установить точную версию зависимостей, и вам не нужно будет их фиксировать. Зачем вам добавлять в свой репозиторий 10000 файлов зависимостей, если вы не должны их обновлять. Если вам требуется изменить что-то из этого, вы должны раскошелиться и внести свои изменения там. И если вы беспокоитесь о необходимости извлекать фактические зависимости каждый раз при сборке или выпуске, у composer есть разные способы решения этой проблемы, кэш, zip-файлы и т. Д.

Затем вы фиксируете composer.json в своем проекте, и все остальные члены вашей команды могут запустить composer install для установки зависимостей вашего проекта.

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

Это означает, что если что-либо было зафиксировано с момента последней установки composer, то без файла блокировки вы получите новый сторонний код, который будет удален.

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

Источник: Композитор: Все дело В файле блокировки.

Зафиксируйте составителя вашего приложения.блокировка (вместе с composer.json) в системе управления версиями. Это важно, потому что команда установки проверяет, присутствует ли файл блокировки, и если он есть, она загружает указанные там версии (независимо от того, что говорит composer.json). Это означает, что любой, кто настроит проект, загрузит точно такую же версию зависимостей. Ваш CI-сервер, производственные машины, другие разработчики в вашей команде, все и каждый работают на одних и тех же зависимостях, что снижает вероятность ошибок, затрагивающих только некоторые части развертываний. Даже если вы разрабатываете в одиночку, через шесть месяцев при переустановке проекта вы можете быть уверены, что установленные зависимости все еще работают, даже если с тех пор ваши зависимости выпустили много новых версий.

Источник: Композитор - Основное использование.

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

Исключение составляют случаи, когда вы используете мета-приложения, библиотеки, в которых зависимости должны обновляться при установке (например, Каркасное приложение Zend Framework 2 ). Таким образом, цель состоит в том, чтобы захватить последние зависимости каждый раз, когда вы хотите начать развиваться.

^{Источник: Композитор: Все дело В файле блокировки}

См. также: В чем разница между обновлением composer и установкой composer?