Я немного запутался в composer.lock, используемом в приложении с репозиторием.
Я видел много людей, говорящих, что мы не должны .gitignore composer.lock из репозитория.
Если я обновляю свои библиотеки в своей среде dev, у меня будет новый 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, потому что вы не знаете, как это повлияет на стабильность вашего кода. Могут быть ошибки с новыми зависимостями, это может изменить способ поведения вашего приложения, который может повлиять на ваш собственный, он может быть несовместим с другими зависимостями и т.д. Вы должны сделать это в среде dev, следуя правильному тестированию QA и регрессии и т.д..
2. Вы должны управлять версиями вашего файла 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 в системе версии будет хранить точную версию этих подзависимостей, значит, когда вы и ваш партнер по команде создаете композитор (таким образом вы будете устанавливать свои зависимости на основе composer.lock), вы оба получите одинаковые версии.
Что делать, если вы хотите обновить? Затем в вашей среде dev выполните: composer update, это создаст новый файл composer.lock(если есть что-то новое), и после того, как вы его протестируете, и тест QA и регрессионный тест это и прочее. Вы можете нажать на него для всех остальных, чтобы загрузить новый composer.lock, так как он безопасен для обновления.
3. Вы не должны контролировать ваши фактические зависимости, потому что это не имеет смысла. С composer.lock вы можете установить точную версию зависимостей, и вам не нужно будет их фиксировать. Почему вы добавляете в свои репо 10000 файлов зависимостей, когда вы не должны их обновлять. Если вам нужно изменить одно из них, вы должны раскошелиться и внести туда свои изменения. И если вы обеспокоены необходимостью получения фактических зависимостей каждый раз сборки или выпуска, у композитора есть разные способы облегчить эту проблему, кеш, zip файлы и т.д.
Затем вы передаете
composer.jsonвашему проекту, и все остальные члены вашей команды могут выполнить установку композитора для установки зависимостей между проектами.Точка файла блокировки - это запись точных версий, которые установлены, чтобы их можно было повторно установить. Это означает, что если у вас есть спецификация версии 1. *, и ваш сотрудник запускает обновление для композитора, которое устанавливает 1.2.4, а затем записывает файл composer.lock, когда вы устанавливаете композитор, вы также получите 1.2.4, даже если версия 1.3.0 была выпущена. Это гарантирует, что все, кто работает над проектом, имеют одинаковую точную версию.
Это означает, что если что-либо было совершено с момента установки компоновщика в последний раз, без файла блокировки, вы получите новый сторонний код, который будет вытащен.
Опять же, это проблема, если вы беспокоитесь о нарушении кода. И одна из причин, почему его важно думать о композиторе как о центре файла composer.lock.
Источник: Композитор: все о файле блокировки.
Завершите свое приложение composer.lock(вместе с composer.json) в управление версиями. Это важно, потому что команда установки проверяет наличие файла блокировки, и если это так, он загружает версии, указанные там (независимо от того, что говорит композитор .json). Это означает, что любой, кто устанавливает проект, загрузит ту же самую версию зависимостей. Ваш сервер CI, производственные машины, другие разработчики в вашей команде, все и все работают на одних и тех же зависимостях, что уменьшает вероятность ошибок, затрагивающих только некоторые части развертываний. Даже если вы разрабатываете самостоятельно, через шесть месяцев при переустановке проекта вы можете быть уверены, что установленные зависимости все еще работают, даже если ваши зависимостей выпустили много новых версий с тех пор.
Источник: Композитор - основное использование.
Если вы беспокоитесь о нарушении кода, вы должны передать composer.lock вашей системе управления версиями, чтобы убедиться, что все ваши сотрудники проекта используют одну и ту же версию кода. Без файла блокировки каждый раз вы будете получать новый сторонний код.
Исключением является использование мета-приложений, библиотек, в которых необходимо обновлять зависимости при установке (например, Zend Framework 2 Skeleton App). Поэтому целью является захват последних зависимостей каждый раз, когда вы хотите начать разработку.
Источник: Композитор: его все о файле блокировки
Смотрите также: В чем разница между установкой композитора и установкой композитора?
Там нет точного ответа на это.
Вообще говоря, 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 и иногда даже не имеют смысла (help говорит, что install принимает имя пакета, но при попытке его использовать говорит "нет").).
Чтобы обновить блокировку или применить изменения от json, вам нужно использовать update, и вы можете не захотеть обновлять все. Замок имеет приоритет при выборе того, что должно быть установлено. Если есть файл блокировки, это то, что использовал. Вы можете ограничить обновление, но система все еще в беспорядке.
Обновление требует времени, концертов оперативной памяти. Я также подозреваю, что если вы возьмете проект, который не был затронут какое-то время, он выглядел из версий, которые он имеет, со временем их станет больше, и, вероятно, это не будет сделано эффективно, что просто душит его.
Они очень хитры, когда речь идет о секретных составных командах, которые нельзя ожидать, чтобы они были составными. По умолчанию команда удаления композитора отображается для сопоставления с обновлением композитора и удаления композитора, например.
Вопрос, который вам действительно нужно задать, заключается не в том, следует ли вам сохранять блокировку в дереве исходных кодов, или, наоборот, стоит ли сохранять это где-то каким-либо образом или нет, а скорее вы должны задавать вопрос о том, что на самом деле делает, тогда вы можете решить для себя когда вам нужно сохранить это и где.
Я укажу, что возможность иметь блокировку - это большое удобство, когда у вас есть надежная стратегия сохранения внешних зависимостей, так как она отслеживает информацию, полезную для отслеживания этого (происхождение) и обновления, но если вы этого не делаете тогда это ни здесь, ни там. Бесполезно, когда оно заставляет горло сдавливать как обязательную опцию, загрязняющую ваши исходные деревья. Это очень распространенная вещь, которую можно найти в унаследованных кодовых базах, где люди внесли много изменений в composer.json, которые на самом деле не были применены и ломаются, когда люди пытаются использовать composer. Нет composer.lock, нет проблемы с рассинхронизацией.