Должен ли я зафиксировать файл yarn.lock и для чего он нужен?
Пряжа создает yarn.lock файл после выполнения yarn install,
Должно ли это быть зафиксировано в хранилище или проигнорировано? Для чего это?
7 ответов
Да, вы должны проверить это, см. Миграция с npm
Yarn сгенерирует файл yarn.lock в корневом каталоге вашего пакета. Вам не нужно читать или понимать этот файл - просто проверьте его в системе контроля версий.
Зависит от того, что ваш проект:
- Ваш проект - приложение? Тогда: да
- Ваш проект - библиотека? Если так: нет
Более подробное описание этого можно найти в этой проблеме GitHub, где один из создателей пряжи, например. говорит:
В package.json описываются предполагаемые версии, требуемые первоначальным автором, а в yarn.lock описывается последняя известная конфигурация для данного приложения.
Только yarn.lock-файл проекта верхнего уровня будет использован. Так что, если один проект не будет использоваться автономно и не будет установлен в другой проект, то нет смысла совершать какие-либо yarn.lock-файл - вместо этого всегда будет до package.json-файл, чтобы передать, какие версии зависимостей ожидает проект.
Я вижу, что это два отдельных вопроса в одном. Позвольте мне ответить на оба.
Вы должны зафиксировать файл в репо?
Да. Как упоминалось в ответе ckuijjer, в Руководстве по миграции рекомендуется включить этот файл в репозиторий. Читайте дальше, чтобы понять, почему вам нужно это сделать.
Что такое yarn.lock ?
Это файл, в котором хранятся точные версии зависимостей для вашего проекта вместе с контрольными суммами для каждого пакета. Это способ обеспечения согласованности для ваших зависимостей.
Чтобы понять, зачем нужен этот файл, сначала нужно понять, в чем была проблема оригинального NPM. package.json, Когда вы устанавливаете пакет, NPM будет хранить диапазон разрешенных ревизий зависимости вместо конкретной ревизии (semver). NPM будет пытаться получить обновление самой последней версии зависимости в указанном диапазоне (т. Е. Исправления обновления без прерываний). Есть два проблемы с этим подходом.
Авторы зависимостей могут выпускать обновления версий исправлений, хотя на самом деле вносят существенные изменения, которые повлияют на ваш проект.
Два разработчика работают
npm installв разное время может появиться разный набор зависимостей. Что может привести к невозможности воспроизведения ошибки в двух абсолютно одинаковых средах. Это может вызвать проблемы стабильности сборки для серверов CI, например.
Пряжа, с другой стороны, идет по пути максимальной предсказуемости. Это создает yarn.lock файл для сохранения точных версий зависимостей. При наличии этого файла пряжа будет использовать версии, хранящиеся в yarn.lock вместо разрешения версий из package.json, Эта стратегия гарантирует, что ни одна из проблем, описанных выше, не произойдет.
yarn.lock похож на npm-shrinkwrap.json которые могут быть созданы npm shrinkwrap команда. Проверьте этот ответ, объясняя различия между этими двумя файлами.
Вам следует:
- добавить его в репозиторий и зафиксировать
- использовать
yarn install --frozen-lockfileи нетyarn installпо умолчанию как локально, так и на серверах сборки CI.
(Я открыл тикет в системе отслеживания проблем yarn, чтобы обосновать необходимость использования по умолчанию режима замороженного файла блокировки, см. #4147).
Остерегайтесь НЕ устанавливать frozen-lockfile флаг в .yarnrcfile, так как это помешает вам синхронизировать файлы package.json и yarn.lock. См. Соответствующую проблему с пряжей на github
yarn installможет неожиданно изменить ваш yarn.lock, сделав недействительными претензии пряжи о повторяющихся построениях. Вы должны использовать толькоyarn install для инициализации yarn.lock и его обновления.
Кроме того, особенно. в больших командах у вас может быть много шума из-за изменений в замке пряжи только потому, что разработчик настраивал свой локальный проект.
Для получения дополнительной информации прочитайте мой ответ о пакете npm package-lock.json, поскольку он также применим и здесь.
Это также недавно было разъяснено в документации по установке пряжи:
yarn installУстановите все зависимости, перечисленные в package.json, в локальную папку node_modules.
В
yarn.lockфайл используется следующим образом:
- Если yarn.lock присутствует и его достаточно для удовлетворения всех зависимостей, перечисленных в package.json, будут установлены точные версии, записанные в yarn.lock, и yarn.lock останется без изменений. Yarn не проверяет наличие более новых версий.
- Если yarn.lock отсутствует или его недостаточно для удовлетворения всех зависимостей, перечисленных в package.json (например, если вы вручную добавляете зависимость в package.json), Yarn ищет новейшие доступные версии, которые удовлетворяют ограничениям в package..json. Результаты записываются в yarn.lock.
Если вы хотите, чтобы yarn.lock не обновлялся, используйте
--frozen-lockfile.
Не для того, чтобы выступать в роли защитника дьявола, но я медленно (с годами) пришел к мысли, что вы НЕ должны фиксировать файлы блокировки.
Я знаю каждую часть имеющейся у них документации, в которой говорится, что вы должны это делать. Но что толку?! И, на мой взгляд, недостатки намного перевешивают преимущества.
По сути, я потратил бесчисленное количество часов на отладку проблем, которые в конечном итоге были решены путем удаления файлов блокировки. Например, файлы блокировки могут содержать информацию о том, какой реестр пакетов использовать, и в корпоративной среде, где разные пользователи обращаются к разным реестрам, это рецепт катастрофы.
Кроме того, файлы блокировки могут действительно испортить ваше дерево зависимостей. Поскольку yarn и npm создают сложное дерево и хранят внешние модули разных версий в разных местах (например, в папке node_modules внутри модуля в верхней папке node_modules вашего приложения), если вы часто обновляете зависимости, это может создать настоящий беспорядок. Опять же, я потратил массу времени, пытаясь выяснить, какая старая версия модуля все еще использовалась в зависимости, в которой версия модуля была обновлена, только чтобы обнаружить, что удаление файла блокировки и папки node_modules решило все сложные -диагностировать проблемы.
У меня даже есть псевдонимы оболочки, которые удаляют файлы блокировки (а иногда и папки node_modules!) Перед запуском yarn или npm.
Думаю, это всего лишь обратная сторона медали, но слепое следование этой догме может стоить вам........
Из моего опыта я бы сказал, что да, мы должны совершить yarn.lock файл. Это гарантирует, что когда другие люди будут использовать ваш проект, они получат те же зависимости, что и ваш проект.
Когда вы запускаете yarn или yarn add, Yarn генерирует файл yarn.lock в корневом каталоге вашего пакета. Вам не нужно читать или понимать этот файл - просто проверьте его в системе контроля версий. Когда другие люди начинают использовать Yarn вместо npm, файл yarn.lock гарантирует, что они получат точно такие же зависимости, как и вы.
Можно утверждать, что мы можем достичь этого путем замены ^ с --, Да, мы можем, но в целом мы видели, что большинство npm пакеты идут с ^ нотации, и мы должны изменить нотацию вручную для обеспечения статической зависимости версии. Но если вы используете yarn.lock это программно обеспечит вашу правильную версию.
Также как Эрик Эллиотт сказал здесь
Не.gitignore пряжи. Это необходимо для обеспечения детерминированного разрешения зависимостей, чтобы избежать ошибок "работает на моей машине".
Я предполагаю, что да, поскольку Yarn имеет свой собственный файл yarn.lock: https://github.com/yarnpkg/yarn
Используется для детерминированного разрешения зависимостей пакетов.
Да, ты должен это совершить. Для получения дополнительной информации о файле yarn.lock обратитесь к официальным документам здесь.
Да! yarn.lock должен быть зарегистрирован, чтобы любой разработчик, который устанавливает зависимости, получал точно такой же вывод! Например, с помощью npm [которая была доступна в октябре 2016 года) вы можете получить patch версия (скажем, 1.2.0) установлена локально, в то время как новый разработчик работает install может получить другую версию (1.2.1).