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

305

Пряжа создает yarn.lockфайл после выполнения yarn install.

Должно ли это быть зафиксировано в хранилище или проигнорировано? Для чего это?

yarnpkg

— rlay3
источник

3

ИМХО, этот вопрос (и большинство приведенных ниже ответов) являются неполными из-за отсутствия вопроса: «Как и когда мы должны восстановить файл yarn.lock?»

— MarkHu

1

Знаете ли вы сейчас, как и когда?

— Джаярджо

@MarkHu нашел его здесь: yarnpkg.com/lang/en/docs/yarn-lock/#toc-managed-by-yarn Итак, в основном:

Your yarn.lock file is auto-generated and should be handled entirely by Yarn. As you add/upgrade/remove dependencies with the Yarn CLI, it will automatically update your yarn.lock file.

— jayarjo

Связанный: stackoverflow.com/questions/45614973/…

— k0pernikus

271

Да, вы должны проверить это, см. Миграция с npm

Yarn сгенерирует файл yarn.lock в корневом каталоге вашего пакета. Вам не нужно читать или понимать этот файл - просто проверьте его в системе контроля версий.

— ckuijjer
источник

33

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

— rlay3

13

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

— rlay3

Вместо того, чтобы говорить "файл блокировки не найден". Надо просто сказать «Генерация файла yarn.lock». Дух :) Это не ошибка, но первое звучит как ошибка. И последний будет достаточно тревожным для любого в обратном сценарии (где они ожидают иметь файл yarn.lock, но, очевидно, не имеют).

— Александр Миллс

7

Я ценю, что yarn.lock блокирует наш проект для определенных версий пакетов, но я чувствую, что использование слова «блокировка» является неудачным. Обычно блокирующие файлы (такие как .ldb ) являются средством ограничения ресурса одним процессом за раз, чтобы предотвратить повреждение, которое может привести к появлению промежуточных обновлений. Такие файлы блокировок определенно не должны быть привязаны к контролю версий, что, возможно, является причиной большинства недоразумений относительно yarn.lock.

— Энтони

2

Мне действительно не нравится фраза "вам не нужно читать или понимать этот файл". Это важный файл для поддержки вашего проекта.

— Натан

83

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

Ваш проект - приложение? Тогда: да
Ваш проект - библиотека? Если так: нет

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

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

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

— VoxPelli
источник

7

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

— E_net4 нравится downvotes

1

Если я правильно прочитал ваше описание, то "Является ли ваш проект библиотекой?" можно ответить «Если хочешь». Похоже, у него нет недостатков, но он может быть полезен, если у вас есть сложные devDependencies и вы хотите, чтобы у каждого разработчика вашей библиотеки были одинаковые сборки и тестируемые скрипты. Правильно?

— Пипо

4

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

— VoxPelli

1

Дарт имеет ту же систему с pubspec.yaml и pubspec.lock и рекомендует то же, что и в ответе. Смотрите этот вопрос и эту запись документации.

— Джонас Келло

16

Пожалуйста, смотрите эту запись в официальном блоге Yarn: файлы блокировки должны быть зафиксированы во всех проектах

— E_net4 нравится downvotes

66

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

Вы должны зафиксировать файл в репо?

Да. Как упомянуто в ответе 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командой. Проверьте этот ответ, объясняя различия между этими двумя файлами.

— Juriy
источник

1

Но я вижу, yarn.lockчто время от времени обновляется, вы знаете, почему и когда это yarnпроисходит?

— Джаярджо

1

Выпуски пряжи # 4379 и # 4147 предполагают, что yarnобновления yarn.lockво многих случаях, включая запуск yarn installбез изменений в package.json. Использование yarn install --frozen-lockfileв соответствии с рекомендациями, приведенными в разделе «Почему запуск yarn в windows, меняет yarn.lock (или настраивает его через .yarnrc)», кажется лучшим выбором.

— Лаури Харпф

НпМ в настоящее время имеет package-lock.jsonи npm ci. Этот рабочий процесс аналогичен нити yarn.lockи yarn install --frozen-lockfile.

— k0pernikus

10

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

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

— jarekwg
источник

8

Вам следует:

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

(Я открыл тикет на трекере проблем пряжи, чтобы установить поведение по умолчанию для Frozen-Lockfile, см. # 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.lock отсутствует или его недостаточно для удовлетворения всех зависимостей, перечисленных в package.json (например, если вы вручную добавляете зависимость в package.json), Yarn ищет новейшие доступные версии, которые удовлетворяют ограничениям в пакете .json. Результаты записываются в yarn.lock.

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

— k0pernikus
источник

Хотя это правда, единственное время, которое я могу подумать, что вам придется использовать, --frozen-lockfileэто если кто-то вручную yarn installобновит package.json без последующего запуска и фиксации обновлений. Поэтому CI может захотеть использовать этот флаг, но разработчики не должны, потому что это скрывает проблемы.

— jkrehm

@jkrehm Зависит от того, что вы имеете в виду, скрывая вопросы. У меня было больше проблем с неожиданно изменившимися yarn.lockфайлами, введенными yarn installлибо путем раздувания запросов на получение, либо из-за ненужных конфликтов слияния, либо путем извлечения разрывающей библиотеки. (Только потому, что библиотека использует semvar, не означает, что обновление / незначительное обновление не сломает ваше приложение - я был там). Я считаю, что обновление yarn.lockдолжно быть только ручным шагом, поэтому я полагаюсь yarn install --frozen-lockfile(и npm ciна проекты npm) даже на мою машину разработчика, поскольку она надежна и детерминирована.

— k0pernikus

1

У меня никогда не было проблемы с yarn.lockнеожиданным обновлением (использовался с октября 2016 года, когда он вышел) Это всегда был пользователь, который делал что-то вручную или паршивый скрипт после установки. По этой причине я предпочитаю Yarn, а не NPM (NPM обновляет все, что захочет). Думаю, мне повезет, что я не столкнулся с этими проблемами.

— jkrehm

5

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

Из док

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

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

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

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

— Anshul
источник

3

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

— Навин Прасад
источник

3

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

— enapupe
источник

1

Упомянутое вами поведение npm зависит от того, как вы сохраняете свои зависимости. Если вы сохраняете с --save-exactпомощью npm, вы можете добиться того же поведения.

— АликанC

4

@AlicanC Я не думаю, что это так просто. Я полагаю, что пряжа (через файл подтвержденной блокировки) будет гарантировать одинаковую версию пакетов и всех их зависимостей . Это то, с чем у NPM всегда были проблемы, потому что зависимость зависимости не может быть привязана к конкретной версии, поэтому новая установка может получить другие зависимости более низкого уровня. NPM Shrinkwrap должен был решить эту проблему в некоторой степени, но это всегда было сложно и очень часто не работает правильно.

— nextgentech

@nextgentech Если в этом случае, как мне убедиться, что зависимость обновляется правильно. Предположим, если у меня есть основной пакет, который имеет несколько (скажем, 3) зависимых пакетов. Я буду следить за изменениями в моем основном пакете и обновлять его в package.json. Но если какой-либо из 3 подпакетов будет обновлен ими, как я получу изменения? Из-за файла блокировки эти зависимости не будут обновлены, верно?

— Pragatheeswaran

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

— nextgentech

yarn installне будет гарантировать те же версии. Только yarn install --frozen-lockfileделает.

— k0pernikus