Стоит ли фиксировать файл yarn.lock и для чего он нужен?

Да, вам следует проверить это, см. Переход с npm

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

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

Зависит от вашего проекта:

1. Ваш проект - приложение? Затем: Да
2. Ваш проект - это библиотека? Если да: Нет.

Более подробное описание этого можно найти в этом выпуске GitHub, где один из создателей Yarn например. говорит:

Package.json описывает предполагаемые версии, желаемые исходным автором, а yarn.lock описывает последнюю известную удачную конфигурацию для данного приложения.

Будет использоваться только yarn.lock-файл проекта верхнего уровня. Таким образом, если один проект не будет использоваться автономно и не будет установлен в другой проект, тогда нет смысла фиксировать какой-либо yarn.lock-файл - вместо этого package.json-файл всегда будет определять, какие версии зависимостей ожидает проект.

Я вижу, что это два отдельных вопроса в одном. Позвольте мне ответить на оба вопроса.

Следует ли передать файл в репозиторий?

да. Как упоминалось в ответе ckuijjer, это рекомендуется в Руководство по миграции, чтобы включить этот файл в репо. Прочтите, чтобы понять, зачем вам это нужно.

Что такое yarn.lock?

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

Чтобы понять, зачем нужен этот файл, вам сначала нужно понять, в чем заключалась проблема package.json оригинального NPM. Когда вы устанавливаете пакет, NPM сохранит диапазон разрешенных ревизий зависимости вместо конкретной ревизии (semver). NPM попытается получить обновление зависимости от последней версии зависимости в указанном диапазоне (т. Е. Неразрывные обновления исправлений). У этого подхода есть две проблемы.

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

2. Два разработчика, запускающие npm install в разное время, могут получить разный набор зависимостей. Это может привести к тому, что ошибка не будет воспроизводиться в двух абсолютно одинаковых средах. Это может вызвать проблемы со стабильностью сборки, например, для серверов CI.

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

yarn.lock аналогичен npm-shrinkwrap.json, который может быть создан командой npm shrinkwrap. Проверьте этот ответ, объясняя различия между этими двумя файлами.

Вам следует:

1. добавить его в репозиторий и зафиксировать
2. используйте yarn install --frozen-lockfile и НЕ yarn install по умолчанию как локально, так и на серверах сборки CI.

(Я открыл тикет в системе отслеживания проблем пряжи, чтобы убедить вас в необходимости использовать поведение по умолчанию для замороженного файла блокировки, см. # 4147).

Не устанавливайте флаг frozen-lockfile в файле .yarnrc, так как это помешает вам синхронизировать файлы 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 ищет новейшие доступные версии, которые удовлетворяют ограничениям в пакете. .json. Результаты записываются в yarn.lock.

Если вы хотите, чтобы yarn.lock не обновлялся, используйте --frozen-lockfile.

Думаю, да, поскольку Yarn использует собственный файл yarn.lock: https://github.com/yarnpkg/yarn

Он используется для детерминированного разрешения зависимостей пакетов.

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

Из документа

Когда вы запускаете yarn или yarn add, Yarn сгенерирует файл yarn.lock в корневом каталоге вашего пакета. Вам не нужно читать или понимать этот файл - просто зарегистрируйте его в системе контроля версий. Когда другие люди начнут использовать Yarn вместо npm, файл yarn.lock гарантирует, что они получат точно такие же зависимости, как и вы.

Можно утверждать, что мы можем добиться этого, заменив ^ на --. Да, мы можем, но в целом мы видели, что большинство npm пакетов поставляется с ^ нотацией, и нам приходится изменять нотацию вручную, чтобы гарантировать статическую версию зависимости. Но если вы используете yarn.lock, это программно обеспечит вашу правильную версию.

Также, как сказал Эрик Эллиот, здесь

Да, вы должны это сделать. Дополнительную информацию о файле yarn.lock см. В официальной документации здесь

Не для того, чтобы играть в адвоката дьявола, но я медленно (с годами) пришел к мысли, что вы НЕ должны фиксировать файлы блокировки.

Я знаю каждую часть имеющейся у них документации, в которой говорится, что вам следует это делать. Но что толку ?! И, на мой взгляд, недостатки намного перевешивают преимущества.

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

Кроме того, файлы блокировки могут действительно испортить ваше дерево зависимостей. Поскольку yarn и npm создают сложное дерево и хранят внешние модули разных версий в разных местах (например, в папке node_modules внутри модуля в верхней папке node_modules вашего приложения), если вы часто обновляете зависимости, это может создать настоящий беспорядок. Опять же, я потратил массу времени, пытаясь выяснить, какая старая версия модуля все еще использовалась в зависимости, в которой версия модуля была обновлена, только чтобы обнаружить, что удаление файла блокировки и папки node_modules решило все сложные -диагностировать проблемы.

У меня даже есть псевдонимы оболочки, которые удаляют файлы блокировки (а иногда и папки node_modules!) Перед запуском yarn или npm.

Думаю, это всего лишь обратная сторона медали, но слепое следование этой догме может стоить вам ........

Да! yarn.lock необходимо зарегистрировать, чтобы любой разработчик, устанавливающий зависимости, получил точно такой же результат! Например, с помощью npm [который был доступен в октябре 2016 года] вы можете установить patch версию (скажем, 1.2.0) локально, пока новый разработчик запускает новую install может получить другую версию (1.2.1).