Там нет точного ответа на это.
Вообще говоря, 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, нет проблемы с рассинхронизацией.