Yarn: Должен ли я помещать yarn.lock в .gitignore?

Вы должны добавить yarn.lock в свой git , не игнорируйте его.

См. Https://yarnpkg.com/en/docs/migrating-from-npm.

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

Для ясности - это также относится и к библиотекам, а не только к приложениям, потому что в отличие от npm-shrinkwrap.json только yarn.lock проекта верхнего уровня, верно? Таким образом, зависимости зависимостей с файлами yarn.lock не будут генерировать ненужных дубликатов. Это полезно для библиотек, если у вас сложные зависимости разработчиков и вы хотите, чтобы каждый участник вашей библиотеки имел одинаковые конфигурации сборки и тестирования.

Это верно?

@goenning
Может быть, не всегда лучше помещать файл yarn.lock в свой репозиторий.
Например, я использую синопию. Поэтому у меня есть собственный реестр npm. Я использую этот реестр в основном для других проектов, где у меня есть частные модули.
Но когда я помещаю общедоступный проект в репозиторий git, который имеет только общедоступные зависимости, yarn.lock имеет неправильные ссылки на зависимости, и моя система CI не сможет построить проект.
Зависимости указывают на мой локальный репозиторий.
Это также может случиться с другими разработчиками, если они клонируют мой репозиторий.
Есть ли способ обойти это, кроме помещения файла yarn.lock в gitignore?

Кроме того, если у вас есть преаутентифицированный реестр npm, например myget который прокси к npm, yarn.lock будет иметь преаутентифицированные ссылки на пакеты, что является серьезным нарушением безопасности 🎉
Это должно быть где-то задокументировано крупным шрифтом.

@Pfeifenjoy, а что, если вы
используя git, вы можете получить доступ к репо с помощью ключа развертывания (через ssh)

@beenotung Я не большой поклонник использования git в качестве диспетчера зависимостей, потому что он очень медленный, не разрешает зависимости так, как я хочу, и, на мой взгляд, лучше всего иметь все зависимости в одном диспетчере.

Кроме того, зависимость, на которую я ссылаюсь, все (не только мои собственные проекты) получат другой адрес, потому что они сохранены в моей локальной учетной записи sinopia. Было бы очень утомительно ссылаться на все модули узлов, от которых зависят мои проекты, в git.
Кроме того, проще удалить файл yarn.lock.

@Pfeifenjoy Может быть конфликт в том, что вы хотите, чтобы пряжа делала? Если вы хотите предоставить способ убедиться, что другие установки имеют ваши зависимости, включите его - он работает так, как задумано. Если вы используете частные репозитории и источники, вы должны быть очень осторожны с тем, как вы делитесь своим кодом, так же, как вы специально игнорируете любые ключи или соли из репо (если вы хотите увидеть предупреждение о проекте readme, я бы сделал запрос функции / pull).

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

@thisolivier звучит разумно

Просто памятка.
Из-за https://github.com/yarnpkg/yarn/issues/3330 , если вы живете в Китае или другой запретной зоне и строите свой модуль с другим реестром (например, taobao), вы должны добавить yarn.lock в .gitignore и напишите package-lock = false в .npmrc.

Вот почему я не фиксирую свой создается yarn.lock ).
Чтобы мои пользователи были довольны и без ошибок при установке, я удаляю yarn - если yarn не предоставит решение с четкой документацией, как решить эту проблему, тогда я соглашусь.
(всегда слышите от разработчика правдивую историю)

Также это делает ваши коммиты действительно уродливыми.

Я не согласен с самым популярным комментарием здесь:

• если в проекте используется npm, зафиксируйте package-lock.json в репо и gitignore yarn.lock
• если в проекте используется пряжа, зафиксируйте yarn.lock в репо и gitignore package-lock.json

То есть вы должны _не_ всегда фиксировать yarn.lock в репо , и, чтобы ответить на вопрос OP, да, вы можете добавить его в .gitignore .

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

Во-первых, нет - только если вы когда-либо используете только общедоступный реестр npm. Хуже того, если вы не авторизованы для своей частной организации в yarn (даже если вы все еще находитесь в npm), а пакет с таким же именем существует в общедоступном реестре, он просто установит не тот, без запроса. Было бы непонятно, почему ваша пряжа устанавливается без ошибок, но приложение не работает при использовании пряжи, но работает при использовании npm.

Во-вторых, многие кодовые базы _ не_ используют пряжу. Дело не в том, «когда они перейдут на пряжу». Почти все мои службы узлов и базовые веб-серверы используют npm и не планируют переходить на yarn. Мне нравится пряжа с React, вот и все.

Как упоминал @Pfeifenjoy выше:

У меня есть собственный реестр npm. Я использую этот реестр в основном для других проектов, где у меня есть частные модули

Но когда я помещаю общедоступный проект в репозиторий git, который имеет только общедоступные зависимости, yarn.lock имеет неправильные ссылки на зависимости, и моя система CI не сможет построить проект.

^ Еще одна вещь, даже когда вы решаете ее локально, вы должны включить решение в yaml или любую другую конфигурацию для CI и в любом другом месте, где вы запускаете приложение - своего рода логика, которая может сказать, когда использовать какой реестр и какую команду - звучит раздражающе и ненужно

Другое дело - если вы поощряете всех всегда фиксировать yarn.lock в репо и никогда не игнорировать его, разработчики начнут использовать yarn в репо, которое уже сильно зависит от npm. Даже в тех случаях, когда он работает нормально, в двух файлах блокировки будет дублирование, и это откроет дверь в ад зависимостей. И вы знаете, что какой-то разработчик зафиксирует ~ 25 тыс. Строк yarn.lock в какой-то момент, испортив график ваших вкладов: joy: