ИМХО, этот вопрос (и большинство приведенных ниже ответов) являются неполными из-за отсутствия вопроса: «Как и когда мы должны восстановить файл 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.
Yarn сгенерирует файл yarn.lock в корневом каталоге вашего пакета. Вам не нужно читать или понимать этот файл - просто проверьте его в системе контроля версий.
Хорошая находка. Я нашел следующее из их документов, которые отвечают «для чего он нужен?»: «Клиент 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, чтобы сообщать, какие версии зависимостей ожидает проект.
С другой стороны, не повлияет ли наличие файла блокировки в библиотечных проектах на воспроизводимость соответствующих тестов?
E_net4 нравится downvotes
1
Если я правильно прочитал ваше описание, то "Является ли ваш проект библиотекой?" можно ответить «Если хочешь». Похоже, у него нет недостатков, но он может быть полезен, если у вас есть сложные devDependencies и вы хотите, чтобы у каждого разработчика вашей библиотеки были одинаковые сборки и тестируемые скрипты. Правильно?
Пипо
4
Поскольку файл блокировки не будет соблюдаться ни одним из пользователей вашей библиотеки, то полагаться на него при разработке библиотеки может дать ложное чувство безопасности
VoxPelli
1
Дарт имеет ту же систему с pubspec.yaml и pubspec.lock и рекомендует то же, что и в ответе. Смотрите этот вопрос и эту запись документации.
Я вижу, что это два отдельных вопроса в одном. Позвольте мне ответить на оба.
Вы должны зафиксировать файл в репо?
Да. Как упомянуто в ответе 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.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.
использовать yarn install --frozen-lockfileи НЕ yarn installпо умолчанию как локально, так и на серверах сборки CI.
(Я открыл тикет на трекере проблем пряжи, чтобы установить поведение по умолчанию для Frozen-Lockfile, см. # 4147 ).
Будьте осторожны, НЕ устанавливайте frozen-lockfileфлаг в .yarnrcфайле, поскольку это не позволит вам синхронизировать файлы package.json и yarn.lock. Смотрите связанную проблему пряжи на GitHub
Кроме того, особенно в больших командах может возникнуть много шума из-за изменений в замке пряжи только потому, что разработчик настраивал свой локальный проект.
Установите все зависимости, перечисленные в 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.
Хотя это правда, единственное время, которое я могу подумать, что вам придется использовать, --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ее, программно обеспечит правильную версию.
Да! yarn.lockнеобходимо проверить, чтобы любой разработчик, устанавливающий зависимости, получал точно такой же вывод! Например, с помощью npm [которая была доступна в октябре 2016 года) вы можете установить patchверсию (скажем, 1.2.0) локально, в то время как новый разработчик, работающий с новой installверсией, может получить другую версию (1.2.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делает.
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.Ответы:
Да, вы должны проверить это, см. Миграция с npm
источник
Зависит от того, что ваш проект:
Более подробное описание этого можно найти в этом выпуске GitHub, где, например, один из создателей Yarn. говорит:
yarn.lockБудет использован только -файл проекта верхнего уровня. Таким образом, если только один проект не будет использоваться автономно и не будет установлен в другом проекте, тогда нет смысла фиксировать любойyarn.lock-file - вместо этого он всегда будет доpackage.json-file, чтобы сообщать, какие версии зависимостей ожидает проект.источник
Я вижу, что это два отдельных вопроса в одном. Позвольте мне ответить на оба.
Вы должны зафиксировать файл в репо?
Да. Как упомянуто в ответе 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.lockчто время от времени обновляется, вы знаете, почему и когда этоyarnпроисходит?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.Я предполагаю, что да, поскольку Yarn имеет свой собственный файл yarn.lock: https://github.com/yarnpkg/yarn
Используется для детерминированного разрешения зависимостей пакетов.
источник
Вам следует:
yarn install --frozen-lockfileи НЕyarn installпо умолчанию как локально, так и на серверах сборки CI.(Я открыл тикет на трекере проблем пряжи, чтобы установить поведение по умолчанию для Frozen-Lockfile, см. # 4147 ).
Будьте осторожны, НЕ устанавливайте
frozen-lockfileфлаг в.yarnrcфайле, поскольку это не позволит вам синхронизировать файлы package.json и yarn.lock. Смотрите связанную проблему пряжи на GitHubyarn installможет неожиданно изменить ваш yarn.lock , делая заявления о повторяемости сборок недействительными. Вы должны использовать толькоyarn installдля инициализации yarn.lock и для его обновления.Кроме того, особенно в больших командах может возникнуть много шума из-за изменений в замке пряжи только потому, что разработчик настраивал свой локальный проект.
Для получения дополнительной информации прочитайте мой ответ о пакете npm package-lock.json, так как это применимо и здесь.
Это также недавно стало ясно в документации по установке пряжи :
источник
--frozen-lockfileэто если кто-то вручнуюyarn installобновит package.json без последующего запуска и фиксации обновлений. Поэтому CI может захотеть использовать этот флаг, но разработчики не должны, потому что это скрывает проблемы.yarn.lockфайлами, введеннымиyarn installлибо путем раздувания запросов на получение, либо из-за ненужных конфликтов слияния, либо путем извлечения разрывающей библиотеки. (Только потому, что библиотека использует semvar, не означает, что обновление / незначительное обновление не сломает ваше приложение - я был там). Я считаю, что обновлениеyarn.lockдолжно быть только ручным шагом, поэтому я полагаюсьyarn install --frozen-lockfile(иnpm ciна проекты npm) даже на мою машину разработчика, поскольку она надежна и детерминирована.yarn.lockнеожиданным обновлением (использовался с октября 2016 года, когда он вышел) Это всегда был пользователь, который делал что-то вручную или паршивый скрипт после установки. По этой причине я предпочитаю Yarn, а не NPM (NPM обновляет все, что захочет). Думаю, мне повезет, что я не столкнулся с этими проблемами.Из моего опыта я бы сказал, что да, мы должны зафиксировать
yarn.lockфайл. Это гарантирует, что когда другие люди будут использовать ваш проект, они получат те же зависимости, что и ваш проект.Из док
Можно утверждать, что мы можем достичь этого путем замены
^на--. Да, мы можем, но в целом мы видели, что большинствоnpmпакетов поставляются с^нотацией, и мы должны изменить нотацию вручную для обеспечения версии статической зависимости. Но если вы используетеyarn.lockее, программно обеспечит правильную версию.Также как Эрик Эллиотт сказал здесь
источник
Да, вы должны совершить это. Для получения дополнительной информации о файле yarn.lock обратитесь к официальным документам здесь.
источник
Да!
yarn.lockнеобходимо проверить, чтобы любой разработчик, устанавливающий зависимости, получал точно такой же вывод! Например, с помощью npm [которая была доступна в октябре 2016 года) вы можете установитьpatchверсию (скажем, 1.2.0) локально, в то время как новый разработчик, работающий с новойinstallверсией, может получить другую версию (1.2.1).источник
--save-exactпомощью npm, вы можете добиться того же поведения.yarn upgradeкоманда вступает в игру. Эта команда обновит все пакеты и заново создаст файл блокировки. Так, например, если вы развертываете приложение в производство и вам нужно установить зависимости, оно будет делать это на основе файла блокировки, извлеченного из хранилища. Вы никогда не должны запускаться,yarn upgradeесли вы явно не хотите изменить информацию о зависимостях (и, таким образом, зафиксировать новый файл блокировки).yarn installне будет гарантировать те же версии. Толькоyarn install --frozen-lockfileделает.