Должен ли composer.lock поддерживать контроль версий?

Я немного запутался с composer.lockиспользованием в приложении с хранилищем.

Я видел, как многие люди говорили, что мы не должны .gitignore composer.lockиз хранилища.

Если я обновлю свои библиотеки в своей среде разработки, у меня будет новая composer.lockверсия, но я не смогу обновить ее до рабочей версии, не так ли?

Не приведет ли это к конфликтам в этом файле?

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

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

Наличие этого в хранилище гарантирует, что каждый разработчик использует одинаковые версии.

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

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

Передайте composer.lock вашего приложения (вместе с composer.json) в систему управления версиями.

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

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

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

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

И говорится здесь :

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

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

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

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

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

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

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

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

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

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 event-dispatcher 2.4.1, а кто-то в вашей команде может иметь Laravel 4.1.31 с event-dispatcher 2.6.5, все будет зависеть от того, когда был последний раз, когда вы запустили установку композитора.

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

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

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

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

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

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

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

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

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

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

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

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

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

Смотрите также: Каковы различия между обновлением композитора и его установкой?

Там нет точного ответа на это.

Вообще говоря, composer не должен делать то, для чего предназначена система сборки, и вы не должны помещать composer.lock в VCS. Композитор может быть странным образом задом наперед. Конечные пользователи, а не производители не должны использовать файлы блокировки. Обычно ваша система сборки хранит снимки, многоразовые каталоги и т. Д., А не пустой каталог каждый раз. Люди, извлекающие библиотеку из composer, могут захотеть, чтобы эта библиотека использовала блокировку, чтобы были проверены зависимости, загружаемые библиотекой.

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

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

SVN может делать это лучше, чем git, поскольку он не заставляет вас приобретать весь репозиторий (хотя я подозреваю, что на самом деле он и не нужен строго для git, но поддержка этого ограничена и обычно не используется). Простые репозитории сборки - это просто ветвь оверлея, в которую вы объединяете / экспортируете дерево компоновки. Некоторые люди объединяют внешние ресурсы в своем дереве исходных текстов или разделяют дополнительные, внешние, сборочные и исходные деревья. Обычно он служит двум целям: кеширование сборки и повторяемые сборки, но иногда разделение их хотя бы на некотором уровне также позволяет легко создавать новые / пустые сборки и несколько сборок.

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

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

Аргументы, выдвигаемые людьми для блокировки файлов, - это случаи, когда они приняли очень конкретное и ограниченное представление о проблеме. Хотите повторяемые сборки и последовательные сборки? Включите папку поставщика в VCS. Затем вы также ускоряете выборку ресурсов, и вам не нужно зависеть от потенциально поврежденных внешних ресурсов во время сборки. Ни один из создаваемых и развертываемых мной конвейеров не требует внешнего доступа, за исключением случаев, когда это абсолютно необходимо. Если вам нужно обновить внешний ресурс, он будет один и только один раз. То, что композитор пытается достичь, имеет смысл для распределенной системы, за исключением того, что упоминалось ранее, и не имеет смысла, поскольку в результате он может оказаться в аду зависимости библиотек для обновлений библиотек с общими конфликтами и обновлениями, которые будут работать медленнее, чем самый медленный для обновления пакета.

Дополнительно я свирепо обновляюсь. Каждый раз, когда я разрабатываю, я обновляю и проверяю все. Есть очень крошечное окно для проникновения значительных версий. Реально также, когда семантическое управление версиями поддерживается, как правило, для композитора, вы не предполагаете, что у вас будет столько проблем совместимости или поломок.

В composer.json вы помещаете нужные вам пакеты и их версии. Вы можете заблокировать версии там. Однако эти пакеты также имеют зависимости с динамическими версиями, которые не будут заблокированы composer.json (хотя я не понимаю, почему вы не можете также поместить их туда самостоятельно, если вы хотите, чтобы они были заблокированы по версии), так что кто-то еще запускает установку composer получает что-то другое без замка. Вы можете не заботиться об этом, или вы можете заботиться, это зависит. Должны ли вы заботиться? Вероятно, хотя бы немного, этого достаточно, чтобы вы знали об этом в любой ситуации и о потенциальном воздействии, но это также может не быть проблемой, если у вас всегда есть время, чтобы просто СУХОЙ запускать сначала и исправить все, что было обновлено.

Композитор хлопот пытается избежать, иногда просто не существует, и хлопоты, связанные с файлами блокировки композитора, могут быть существенными. Они не имеют абсолютно никакого права сообщать пользователям, что им следует или не следует делать в отношении сборки по сравнению с исходными ресурсами (будь то объединение отдельных в VCS), поскольку это не их дело, они не являются главой вас или меня. «Композитор говорит» - это не авторитет, они не ваш начальник и не дают никому превосходства в этом вопросе. Только вы знаете свою реальную ситуацию и что лучше для этого. Тем не менее, они могут посоветовать курс действий по умолчанию для пользователей, которые не понимают, как все работает, и в этом случае вы можете захотеть следовать этому, но лично я не думаю, что это ». реальная замена знания того, как все работает, и способности правильно отработать ваши требования. В конечном счете, их ответ на этот вопрос является лучшим предположением. Люди, которые делают композитор, не знают, где вы должны хранить свой composer.lock, и не должны. Их единственная обязанность - рассказать вам, что это такое и что он делает. Помимо этого вам нужно решить, что лучше для вас.

Сохранение файла блокировки проблематично для удобства использования, потому что composer очень скрытно использует ли он блокировку или JSON и не всегда хорошо использует оба вместе. Если вы запускаете install, он использует только файл блокировки, он будет выглядеть так, если вы добавите что-то в composer.json, он не будет установлен, потому что он не в вашей блокировке. Не совсем понятно, что на самом деле делают операции и что они делают в отношении файла json / lock и иногда даже не имеют смысла (в справке говорится, что установка требует имя пакета, но при попытке его использовать говорит «нет»). ).

Чтобы обновить блокировку или применить изменения от json, вам нужно использовать update, и вы можете не захотеть обновлять все. Замок имеет приоритет при выборе того, что должно быть установлено. Если есть файл блокировки, это то, что используется. Вы можете ограничить обновление, но система все еще в беспорядке.

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

Они очень хитры, когда речь идет о секретных составных командах, которые нельзя ожидать, чтобы они были составными. По умолчанию команда удаления композитора отображается для сопоставления с обновлением композитора и удаления композитора, например.

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

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

Да, очевидно.

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

Если файл блокировки недоступен в vcs, компоновщик укажет на файл composer.json для установки последних зависимостей или версий.

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