Чи слід вчинити файл yarn.lock і для чого він потрібен?

304

Пряжа створює yarn.lockфайл після виконання yarn install.

Чи слід це звертати до сховища чи ігнорувати? Для чого це?

yarnpkg

— rlay3
джерело

3

ІМХО, це запитання (і більшість наведених нижче відповідей) є неповним через відсутність запитання "Як і коли нам відновити файл yarn.lock?"

— MarkHu

1

Тепер ви знаєте, як і коли?

— jayarjo

@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.lock у кореневому каталозі вашого пакета. Вам не потрібно читати чи розуміти цей файл - просто перевірте його в контролі джерела.

— ckuijjer
джерело

33

Приємна знахідка. Я знайшов у своїх документах таке, що відповідає "для чого це?": "Клієнт npm встановлює залежності в каталог node_modules недетерміновано. Це означає, що на основі встановлених залежностей встановлено структуру node_modules Каталог може відрізнятися від людини до іншої. Ці відмінності можуть спричинити помилки, які потребують тривалого часу, щоб "виправити роботу на моїй машині". "

— rlay3

13

Продовження: "Пряжа вирішує ці проблеми навколо версій та недетермінізму за допомогою замкових файлів та алгоритму встановлення, який є детермінованим та надійним. Ці фіксатори блокують встановлені залежності у певній версії та гарантують, що кожна установка приводить до такої самої структури файлів у node_modules на всіх машинах. "

— rlay3

Замість того, щоб сказати "жодного блочного файлу не знайдено". Слід просто сказати "Генерування файлу yarn.lock". Дух :) Це не помилка, але колишня звучить як помилка. І останнє буде досить тривожним для тих, хто в зворотному сценарії (де вони розраховують мати файл yarn.lock, але, мабуть, ні).

— Олександр Міллс

7

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

— Антоній

2

Мені дуже не подобається фраза "вам не потрібно читати чи розуміти цей файл". Це важливий файл для підтримки вашого проекту.

— Натан іде

83

Залежить від вашого проекту:

Ваш проект є додатком? Потім: Так
Ваш проект - бібліотека? Якщо так: Ні

Більш детальний опис цього можна знайти в цьому випуску GitHub, де один із творців Пряжі, наприклад. каже:

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

Використовуватиметься лише yarn.lock-файл проекту верхнього рівня. Отже, якщо проект не буде використовуватися окремо і не буде встановлено в інший проект, тоді не потрібно використовувати жодного yarn.lockфайлу - натомість -файл завжди буде package.jsonдоносити, які версії залежностей очікує проект тоді.

— VoxPelli
джерело

7

З іншого боку, не вплинуло б на те, що файл блокування у бібліотечних проектах відтворює їхні тести?

— E_net4 весь час перейменований

1

Якщо я прочитав ваш опис правильно, ніж "Чи є ваш проект бібліотекою?" можна відповісти "Якщо ти хочеш". Здається, це не має недоліків, але може бути корисним, якщо у вас складні devDependitions і ви хочете, щоб кожен розробник вашої lib мав однакові сценарії побудови та тестування. Правильно?

— Піпо

4

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

— VoxPelli

1

Dart має ту саму систему з pubspec.yaml та pubspec.lock і рекомендує ту ж, що і у відповіді. Дивіться це питання та цю документацію.

— Йонас Келло

16

Будь ласка, дивіться цей запис в офіційному блозі Пряжа: Файли блокування повинні здійснюватися у всіх проектах

— E_net4 перейменовується весь час

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командою. Перевірте цю відповідь, пояснюючи відмінності між цими двома файлами.

— Юрій
джерело

1

Але я бачу, що yarn.lockчас від часу оновлюється, чи знаєте ви, чому і коли yarnце робиться?

— jayarjo

1

Випуски про пряжу № 4379 та # 4147 пропонують yarnоновлення yarn.lockу багатьох випадках, включаючи запуск yarn installбез змін пакета.json. Використання, yarn install --frozen-lockfileяк було запропоновано в розділі Чому запуск пряжі на Windows змінює yarn.lock (або налаштовуючи її через .yarnrc), здається, найкраща ставка.

— Лаурі Харпф

npm на сьогоднішній день має a package-lock.jsonі a npm ci. Цей робочий процес є аналогічним пряжі yarn.lockта yarn install --frozen-lockfile.

— k0pernikus

10

Я думаю, що так, оскільки версія "Пряжа" має власний файл yarn.lock: https://github.com/yarnpkg/yarn

Він використовується для детермінованого вирішення залежності пакета.

— jarekwg
джерело

8

Ти повинен:

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

(Я відкрив квиток на трекері випуску пряжі, щоб зробити випадок, щоб зробити поведінку за замовчуванням замок-файлом за замовчуванням, див. № 4147 ).

Слідкуйте за тим, щоб НЕ встановити frozen-lockfileпрапор у .yarnrcфайлі, як це заважатиме вам синхронізувати файл package.json та yarn.lock. Дивіться відповідну проблему пряжі на github

yarn installможе несподівано вимкнути ваш yarn.lock , зробивши заявки на нитки щодо повторюваних збірок недійсними. Вам слід використовувати лише yarn installініціалізацію yarn.lock та її оновлення.

Також esp. у великих командах ви можете чути шум навколо змін у замці пряжі лише тому, що розробник розробляв їх локальний проект.

Для отримання додаткової інформації читайте мою відповідь про npm's 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), Пряжа шукає новітні доступні версії, які задовольняють обмеження в пакеті .json. Результати записуються на yarn.lock.

Якщо ви хочете переконатися, що yarn.lock не оновлюється, скористайтеся --frozen-lockfile.

— k0pernikus
джерело

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

— jkrehm

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

— k0pernikus

1

У мене жодного разу не виникало проблем із yarn.lockоновленням несподівано (користувався з жовтня 2016 року, коли він з’явився). Це завжди був користувач, який робив щось вручну або невдалий сценарій після встановлення. Тому я віддаю перевагу пряжі над NPM (NPM оновлює все, що завгодно). Я думаю, я вважаю себе щасливим, що не стикався з цими питаннями.

— jkrehm

5

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

Від док

Коли ви запускаєте пряжу або додавання пряжі, пряжа генерує файл yarn.lock в кореневому каталозі вашого пакета. Вам не потрібно читати чи розуміти цей файл - просто перевірте його в контролі джерела. Коли інші люди почнуть використовувати Пряжу замість npm, файл yarn.lock гарантує, що вони отримають точно такі ж залежності, як і ви.

Можна стверджувати, що ми можемо досягти цього, замінивши ^на --. Так, ми можемо, але в цілому ми бачили, що більшість npmпакетів постачається з ^позначеннями, і нам потрібно змінити позначення вручну для забезпечення yarn.lockверсії статичної залежності. Але якщо ви будете використовувати її, програмно забезпечите правильну версію.

Також, як тут сказав Ерік Елліотт

Не ігноруйте пряжу. Саме там для забезпечення детермінованого вирішення залежності, щоб уникнути помилок "працює на моїй машині".

— Аншул
джерело

3

Так, ви повинні це зробити. Більш докладної інформації про фото yarn.lock см офіційних документів тут

— Навін прасад
джерело

3

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

— енапупу
джерело

1

Поведінка npm, яку ви згадали, залежить від того, як ви збережете свої залежності. Якщо ви економите --save-exactпри використанні npm, ви можете досягти такої ж поведінки.

— AlicanC

4

@AlicanC Я не думаю, що це так просто. Я вважаю, що пряжа (через закріплений файл блокування) гарантуватиме таку ж версію пакетів та всі їх залежності . З цим завжди виникали проблеми, пов'язані з NPM, оскільки залежність залежності може не бути прив’язана до конкретної версії, тому нова установка може мати різні залежності нижчого рівня. NPM термоусадка повинна була певною мірою вирішити цю проблему, але вона завжди була складною і дуже часто не працює належним чином.

— nextgentech

@nextgentech Якщо в такому випадку я переконуюсь, що залежність залежно від оновлення оновлена Припустимо, якщо у мене є основний пакет, який містить декілька (скажімо 3) пакетів, залежних від цього. Я буду стежити за змінами в своєму основному пакеті та оновлювати його в package.json. Але якщо будь-який з 3-х підпакетів буде оновлений ними, як я отримаю зміни? Через файл блокування ці залежності не будуть оновлені, правда?

— Pragatheeswaran

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

— nextgentech

yarn installне забезпечить однакові версії. Тільки yarn install --frozen-lockfileробить.

— k0pernikus