Мы используем yarn для всех наших детерминированных установок pkg, но не мешаем пользователю использовать npm - однако я предполагаю, что наличие обоих этих файлов вызовет проблемы. Следует ли добавить его в ваш каталог .gitignore?
Мы используем yarn для всех наших детерминированных установок pkg, но не мешаем пользователю использовать npm - однако я предполагаю, что наличие обоих этих файлов вызовет проблемы. Следует ли добавить его в ваш каталог .gitignore?
Ответы:
Как описано в другом месте, файлы блокировки зависимостей, которые поддерживаются многими системами управления пакетами (например: композитор и сборщик ), должны быть привязаны к базе кода в проектах конца цепочки, чтобы каждый человек, пытающийся запустить этот проект, выполнял так что с точно протестированным набором зависимостей.
Менее ясно, следует ли всегда фиксировать файлы блокировки в пакетах, которые предназначены для включения в другие проекты (где желательны более свободные зависимости). Однако и Yarn, и NPM (как описано в @Cyrille) разумно игнорируют yarn.lock
и, package-lock.json
соответственно, там, где это необходимо, что делает безопасным всегда фиксировать эти файлы блокировки.
Поэтому вы всегдаyarn.lock
package-lock.json
должны фиксировать хотя бы один из или в зависимости от того, какой менеджер пакетов вы используете.
В настоящее время мы имеем две различных системы управления пакетами, которые , как установить один и тот же набор зависимостей от package.json
, но которые генерируют и считываемую из двух различных файлов блокировки. NPM 5 генерирует package-lock.json
, тогда как Yarn генерирует yarn.lock
.
Если вы делаете коммит, package-lock.json
то вы создаете поддержку для людей, устанавливающих ваши зависимости с помощью NPM 5. Если вы делаете коммит yarn.lock
, вы создаете поддержку для людей, устанавливающих зависимости с помощью Yarn.
Независимо от того, выберете ли вы фиксацию yarn.lock
или и то, package-lock.json
и другое, зависит от того, используют ли разработчики вашего проекта только Yarn, NPM 5 или оба. Если ваш проект имеет открытый исходный код, наиболее благоприятным для сообщества способом, вероятно, было бы зафиксировать оба и иметь автоматизированный процесс, чтобы гарантировать yarn.lock
и package-lock.json
всегда оставаться в синхронизации.
Обновление: в Yarn появилась import
команда, которая будет генерировать yarn.lock
файл из package-lock.json
файла. Это может быть полезно для синхронизации двух файлов. (Спасибо @weakish)
Эти вопросы подробно обсуждались в проекте Yarn в:
Оба сейчас закрыты.
yarn import
был представлен в 2018 году. yarnpkg.com/blog/2018/06/04/yarn-import-package-lock
Вы должны зафиксировать 1 файл блокировки дерева зависимостей, но не должны фиксировать оба. Это также требует стандартизации пряжи или npm (но не обоих) для создания и разработки проекта.
Вот статья о пряжи о том, почему следует использовать yarn.lock, если вы стандартизируете пряжу.
Если вы фиксируете как yarn.lock
файл, так и package-lock.json
файлы, существует множество способов, которыми эти 2 файла могут предоставлять разные деревья зависимостей (даже если алгоритмы разрешения дерева yarn и npm идентичны), и нетривиально гарантировать, что они предоставляют именно тот же ответ. Поскольку это нетривиально, маловероятно, что одно и то же дерево зависимостей будет поддерживаться в обоих файлах, и вам не нужно различное поведение в зависимости от того, была ли сборка выполнена с использованием yarn или npm.
Если и когда yarn переключается с использования yarn.lock
на package-lock.json
( проблема здесь ), тогда выбор файла блокировки для фиксации становится легким, и нам больше не нужно беспокоиться о yarn и npm, что приводит к различным сборкам. Основываясь на этом сообщении в блоге , мы не должны ожидать этого изменения в ближайшее время (сообщение в блоге также описывает различия между yarn.lock
и package-lock.json
.
Я думал над тем же вопросом. Вот мои мысли, надеюсь, это поможет:
В документации npm package-lock.json говорится следующее:
package-lock.json автоматически создается для любых операций, в которых npm изменяет дерево node_modules или package.json. Он описывает точное дерево, которое было сгенерировано, так что последующие установки могут генерировать идентичные деревья, независимо от промежуточных обновлений зависимостей.
Это здорово, потому что предотвращает эффект «работает на моей машине».
Без этого файла, если вы npm install --save A
, npm добавит "A": "^1.2.3"
в ваш package.json
. Когда кто - то еще работает npm install
над проектом, вполне возможно , что версия 1.2.4
о A
была выпущена. Поскольку это последняя доступная версия, которая удовлетворяет диапазону semver, указанному в вашем package.json
, она установит эту версию. Но что, если в этой версии появилась новая ошибка? У этого человека возникнет проблема, которую вы не сможете воспроизвести, потому что у вас есть предыдущая версия без каких-либо ошибок.
Исправляя состояние вашего node_modules
каталога, package-lock.json
файл предотвращает эту проблему, потому что у всех будут одинаковые версии всех пакетов.
Но что, если вы пишете и публикуете модуль npm? В документации сказано следующее:
Одна из ключевых особенностей package-lock.json заключается в том, что он не может быть опубликован, и он будет проигнорирован, если найден в любом месте, кроме пакета верхнего уровня.
Таким образом, даже если вы зафиксируете это, когда пользователь установит ваш модуль, он / она не получит package-lock.json
файл, а только package.json
файл. Таким образом, npm установит последнюю версию, которая удовлетворяет диапазонам semver всех ваших зависимостей. Это означает, что вы всегда хотите тестировать свой модуль с этими версиями ваших зависимостей, а не с той, которую вы установили, когда начали писать свой модуль. Так что в таком случае package-lock.json
явно бесполезно. Более того, это может раздражать.
Вот мое практическое правило: если вы работаете над приложением, зафиксируйте файл (ы) блокировки. Если вы поддерживаете библиотеку, добавьте ее в список игнорируемых. В любом случае вы должны использовать точные диапазоны семвера в package.json
. Иегуда Кац (в кэше ) написал отличное объяснение, когда делать коммит Gemfile.lock
(файл блокировки Ruby), а когда нет. По крайней мере, прочтите раздел tl; dr.
.gitignore
и обычно находится в корне проекта.
Вы правы! Разрешение использовать оба npm
и yarn
вызовет проблемы. Взгляните на эту статью .
В настоящее время мы планируем добавить некоторые предупреждения для пользователей, которые используют оба репозитория
yarn
иnpm
в одном и том же репозитории для установки пакетов.Мы настоятельно рекомендуем вам удалить
package-lock.json
файл, если вы решите использовать пряжу, чтобы избежать путаницы в будущем и возможных проблем с согласованностью.
Возможно, вам не нужны оба npm
и в yarn
качестве менеджера пакетов.
Эти файлы управляются вашими инструментами, поэтому - предполагая, что использование yarn будет эффективно обновлять - я package-lock.json
полагаю, фиксация обоих файлов работает нормально.
Я считаю , что самое важное для пользователя является package-lock.json
(я, например, не использовать пряжу) , так это один имеет быть совершено.
Что касается yarn.lock
, это зависит от того, работаете ли вы в одиночку или в команде. Если соло, то, полагаю, нет необходимости совершать это. Если вы (планируете) работать в команде, то вам, вероятно, следует зафиксировать это, по крайней мере, пока yarn не поддерживает это 🙂
Я полагаю, что команда пряжи в конечном итоге перестанет использовать yarn.lock
и будет использовать package-json.lock
вместо этого, на этот раз это станет проще 😛
Нет, одновременное использование обоих файлов блокировки чаще всего приводит к несогласованности в вашем дереве зависимостей, особенно при совместной работе в команде. Игнорирование того или иного замка - простое решение. Просто убедитесь, что ваша команда понимает и соглашается с этим изменением.