Я фиксирую файл package-lock.json, созданный npm 5?

Question

Npm 5 был выпущен сегодня, и одна из новых функций включает детерминированные установки с созданием package-lock.json файл.

Этот файл должен храниться в системе контроля версий?

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

Answer 1

Да, package-lock.json предназначен для проверки в системе контроля версий. Если вы используете npm 5, вы можете увидеть это в командной строке: created a lockfile as package-lock.json. You should commit this file. В соответствии с npm help package-lock.json:

package-lock.json автоматически генерируется для любых операций, где npm изменяет либо node_modules дерево или package.json, Он описывает точное дерево, которое было сгенерировано, так что последующие установки могут генерировать идентичные деревья, независимо от промежуточных обновлений зависимостей.

Этот файл предназначен для фиксации в исходных хранилищах и предназначен для различных целей:

• Опишите единственное представление дерева зависимостей, чтобы товарищи по команде, развертывания и непрерывная интеграция гарантированно устанавливали одинаковые зависимости.

• Предоставить пользователям возможность "путешествовать во времени" в предыдущие состояния node_modules без фиксации самого каталога.

• Для облегчения большей видимости изменений в дереве с помощью читаемых исходных текстов контроля.

• И оптимизировать процесс установки, позволяя npm пропускать повторяющиеся разрешения метаданных для ранее установленных пакетов.

Одна ключевая деталь о package-lock.json является то, что он не может быть опубликован, и он будет игнорироваться, если найден в любом месте, кроме пакета верхнего уровня. Он разделяет формат с npm-shrinkwrap.json(5), который по сути является тем же файлом, но допускает публикацию. Это не рекомендуется, если только не развертывается инструмент CLI или иным образом не используется процесс публикации для создания производственных пакетов.

Если оба package-lock.json а также npm-shrinkwrap.json присутствуют в корне пакета, package-lock.json будет полностью проигнорировано.

Answer 2

Да, ты должен:

1. совершить package-lock.json.
2. использовать npm ci вместо того npm install при создании приложений как на вашем CI, так и на локальной машине разработки

В npm ciрабочий процесс требует наличияpackage-lock.json.

---

Большой недостаток npm install команда - это ее неожиданное поведение, которое может изменить package-lock.json, в то время как npm ci использует только версии, указанные в файле блокировки, и выдает ошибку

• если package-lock.json а также package.json не синхронизированы
• если package-lock.json пропал, отсутствует.

Следовательно, бег npm installлокально, особенно в больших командах с несколькими разработчиками может привести к множеству конфликтов внутриpackage-lock.json и разработчики решили полностью удалить package-lock.json вместо.

Тем не менее, существует веский пример использования возможности быть уверенным в том, что зависимости проекта надежно и многократно разрешаются на разных машинах.

Из package-lock.json вы получите именно это: состояние заведомо работоспособного.

Раньше у меня были проекты без package-lock.json / npm-shrinkwrap.json / yarn.lock файлы, сборка которых однажды завершится ошибкой из-за критического обновления случайной зависимости.

Эту проблему сложно решить, так как иногда приходится угадывать, какая была последняя рабочая версия.

Если вы хотите добавить новую зависимость, вы все равно запустите npm install {dependency}. Если вы хотите обновить, используйте либоnpm update {dependency} или npm install ${dependendency}@{version} и зафиксировать измененный package-lock.json.

Если обновление не удалось, вы можете вернуться к последнему известному работающему package-lock.json.

---

Чтобы процитировать документ npm:

Настоятельно рекомендуется передать сгенерированную блокировку пакета в систему управления версиями: это позволит любому члену вашей команды, вашим развертываниям, вашей CI/ непрерывной интеграции и всем, кто запускает npm install в исходном коде вашего пакета, получить точно такое же дерево зависимостей. что вы развивались. Кроме того, различия этих изменений удобочитаемы и сообщают вам обо всех изменениях, которые npm внес в ваши node_modules, чтобы вы могли заметить, были ли какие-либо транзитивные зависимости обновлены, подняты и т. Д.

А что касается разницы междуnpm ci против npm install:

• У проекта должен быть существующий package-lock.json или npm-shrinkwrap.json.
• Если зависимости в блокировке пакета не совпадают с зависимостями в package.json, npm ci завершится с ошибкой вместо обновления блокировки пакета.
• npm ci можно устанавливать только целые проекты за раз: отдельные зависимости не могут быть добавлены с помощью этой команды.
• Если node_modules уже присутствует, он будет автоматически удален перед npm ci начинает свою установку.
• Он никогда не напишет package.json или любой из пакетных блокировок: установки по существу заморожены.

---

Примечание: я разместил аналогичный ответ здесь

Answer 3

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

Answer 4

Да, лучшая практика - зарегистрироваться

Я согласен, что это вызовет много шума или конфликта при просмотре diff. Но преимущества таковы:

1. гарантировать точно такую ​​же версию каждого пакета. Эта часть является наиболее важной при построении в разных средах в разное время. Вы можете использовать ^1.2.3 в вашем package.json, но как вы можете обеспечить каждый раз npm install подберет одну и ту же версию на вашем компьютере разработчика и на сервере сборки, особенно те пакеты косвенной зависимости? Что ж, package-lock.json будет гарантировать, что. (С помощью npm ci который устанавливает пакеты на основе файла блокировки)
2. это улучшает процесс установки.
3. это помогает с новой функцией аудита npm audit fix (Я думаю, что функция аудита из npm версии 6).

Answer 5

Я не фиксирую этот файл в моих проектах. В чем смысл?

1. Это генерируется
2. Это является причиной ошибки целостности кода SHA1 в gitlab со сборками gitlab-ci.yml

Хотя это правда, что я никогда не использую ^ в моем package.json для библиотек, потому что у меня был плохой опыт с этим:)

С уважением.

Answer 6

Людям, жалующимся на шум при выполнении git diff:

git diff -- . ':(exclude)*package-lock.json'

я использовал псевдоним

alias gd="git diff --ignore-all-space --ignore-space-at-eol --ignore-space-change --ignore-blank-lines -- . ':(exclude)*package-lock.json'"

Answer 7

Вы можете проверить официальные документы npm.

Да, вы можете зафиксировать этот файл. package-lock.json автоматически генерируется для любых операций, где npm изменяет либо node_modules дерево или package.json, Он описывает точное дерево, которое было сгенерировано, так что последующие установки могут генерировать идентичные деревья, независимо от промежуточных обновлений зависимостей.

Answer 8

Да

Ответ — да, обязательно всегда сохраняйте файл блокировки в git.

Аналогия с git-хешами

Если вы используете git, вам следует использовать файл блокировки, поскольку они служат той же цели:

• git -хэш гарантирует стабильность содержимого файлов в git-репозитории.
• файл блокировки гарантирует стабильность содержимого node_modules.

Потому что...

• файлы в репозитории git могут со временем меняться, но хэш git относится к точному снимку файлов.
• Пакеты npm в реестре npm могут со временем меняться, но файл блокировки относится к точному снимку зависимостей.

От самих пакетных менеджеров

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

НПМ

Настоятельно рекомендуется передать сгенерированную блокировку пакета в систему контроля версий...

https://docs.npmjs.com/cli/v6/configuring-npm/package-locks

При установке без файла блокировки вам будет ясно указано зафиксировать файл блокировки:

      npm notice  created a lockfile as package-lock.json. You should commit this file.

пряжа

Файлы блокировки должны быть зафиксированы во всех проектах.

пнпм

Вы всегда должны фиксировать файл блокировки ().

https://pnpm.io/git

Причины

Последовательность

Один коммит должен оставаться неизменным навсегда, а результаты его сборки не должны меняться со временем.

Из НПМ:

[файл блокировки] позволит любому другому участнику вашей команды, вашим развертываниям, вашей CI/непрерывной интеграции и всем, кто запускает npm install в исходном коде вашего пакета, получить точно такое же дерево зависимостей, над которым вы разрабатывали.

Из пряжи:

Если вы не сохраните, какую версию вы установили, кто-то может установить один и тот же набор зависимостей и в итоге получить разные версии в зависимости от того, когда они были установлены. Это может привести к проблемам «Работает на моей машине», и этого следует избегать.

Отслеживание изменений

Когда что-то меняется, вы хотите, чтобы git отслеживал это изменение.

Из НПМ:

[с файлом блокировки] различия от изменений [установки] удобочитаемы для человека и будут информировать вас о любых изменениях, которые npm внес в ваш файл , поэтому вы можете заметить, были ли обновлены, подняты или подняты какие-либо транзитивные зависимости и т. д.

Стабильность и безопасность

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

Из пряжи:

Поскольку авторы пакетов — люди и они могут допустить ошибку, они могут опубликовать случайное критическое изменение в минорной версии или версии исправления. Если вы установите это критическое изменение, когда не собираетесь этого делать, это может иметь плохие последствия, например, нарушение работоспособности вашего приложения.

Если автор пакета либо злоумышленник, либо подвергся нападению со стороны злоумышленника и опубликована плохая версия, вы не хотите, чтобы этот код в конечном итоге запускался без вашего ведома.

Распространенные возражения

"Нет никакого смысла"

Это «Аргумент от незнания», который является логической ошибкой. Другими словами: «Я не знаю причины, значит ее нет».

«Оно создано»

Если этот файл сгенерирован автоматически, зачем нам его фиксировать? Почему npm не может сгенерировать его снова в соответствии с моим package.json.

из комментария

Ответ: генерирование не является недостатком. Генерируются хеши коммитов Git; не следует ли нам использовать git? Правда в том, что файл блокировки не создается детерминированно из package.json, поскольку он зависит от времени и состояния пакетов в реестре npm . Это снимок для стабильности.

«Это вызывает конфликты слияния»

Разрешать конфликты слияния в зарегистрированных файлах блокировки — это бремя.

Из НПМ:

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

Из пряжи:

Когда в файле блокировки возникает конфликт слияния, Yarn автоматически обрабатывает разрешение конфликта при запуске.

https://engineering.fb.com/2017/09/07/web/announcing-yarn-1-0/

Из пнпм:

pnpm может автоматически разрешать конфликты слияния в. Если у вас есть конфликты, просто запуститеи зафиксируйте изменения.

Таким образом, все менеджеры пакетов автоматически разрешают конфликты слияния файлов блокировки . Возможно, в старых версиях этого не было, но сейчас это так.

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

«Конфликты слияний мешают PR и MR»

Использование файлов блокировки значительно увеличивает вероятность того, что объединение одного PR приведет к конфликту второго PR с базовой веткой.

https://docs.renovatebot.com/noise-reduction/#lock-file-considerations

Это верно. Поставщики Git (GitHub, GitLab и т. д.) не разрешают автоматически конфликты файлов блокировки, поэтому это может усложнить слияние. Однако, взвешивая этот минус, помните, что файлы блокировки обычно не изменяются; они меняются только тогда, когда меняются deps или когда разработчик специально меняет файл или установленную версию.отв.

«Это издает дифференциальный шум»

Если инструменты сравнения показывают различия в файлах блокировки, это много шума.

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

«Точные версии достаточно хороши»

Почему бы просто не запрограммировать версию зависимости, избавившись от кареток и тильд (^ и ~)?

комментарий

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

Это неверно. Даже если вы укажете точные версии, ваши зависимости будут иметь свои собственные зависимости, которые могут использовать диапазоны для своих версий, а не точные версии. Таким образом, это не приводит к блокировке всего дерева зависимостей, а только его вершины.

«Файлы блокировки для приложений, файлы блокировки для библиотек отсутствуют»

Примеры такого возражения:

• Синдре Сорхус: «Файлы блокировки для приложений, но не для пакетов» sindresorhus/ama!479
• трастр комментарий

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

Из пряжи:

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

Логически это кажется логичным, но давайте углубимся в проблему.

Статья о пряже углубляется, чтобы развеять это возражение. https://classic.yarnpkg.com/blog/2016/11/24/lockfiles-for-all/Пожалуйста, прочтите это.

Распространенной ошибкой в ​​этом аргументе является мысль о том, что если вы не зафиксируете файл блокировки, его не существует . На самом деле он все еще находится на вашем компьютере и блокирует ваши зависимости. Ситуацию не улучшит игнорирование файла блокировки git.

Если специалист по сопровождению библиотеки хочет постоянно проверять совместимость, ему следует удалить свой файл блокировки (независимо от того, зарегистрирован ли файл блокировки или нет!) Перед установкой и сборкой библиотеки. Единственное отличие от проверенного файла блокировки состоит в том, что у вас есть постоянная запись состояния node_modules, когда это произошло, поэтому ее можно воспроизвести в будущем.

Для этого есть боты, такие как greenkeeper и renovate-bot . Greenkeeper выступает за проверку файлов блокировки (Greenkeeper и Lockfiles: совпадение, заключенное на небесах ), а renovate-bot не выражает никакого мнения, но фиксирует файлы блокировки, если они есть.

«Файлы блокировки генерируются по-разному в разных системах»

Это утверждение упоминалось (например, здесь): разные ОС генерируют разное содержимое файла блокировки. Если это так, то это ошибка.

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

«Файлы блокировки могут представлять угрозу безопасности»

См . Snyk – Почему файлы блокировки npm могут быть слепой точкой безопасности для внедрения вредоносных модулей.

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

Защититесь от этого с помощью проверок CI, таких как lockfile-lint или простоили(на пряже 1) и, возможно, установивлокально в вашем.

Этот риск присутствует всякий раз, когда вы устанавливаете пакет с ненадежным кодом.

В заключение

Всегда фиксируйте файл блокировки.

Answer 9

Да, фиксация package-lock.json является стандартной практикой.

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

Плюсы:-

• Если вы следуете строгому управлению версиями и не разрешаете автоматическое обновление до основных версий, чтобы уберечь себя от обратно несовместимых изменений в сторонних пакетах, фиксация пакетной блокировки очень помогает.
• Если вы обновляете конкретный пакет, он обновляется в package-lock.json, и каждый, кто использует репозиторий, обновляется до этой конкретной версии, когда принимает ваши изменения.

Минусы:-

• Это может сделать ваши запросы на вытягивание некрасивыми:)'

Изменить:- npm install не гарантирует, что все участники проекта используют одну и ту же версию пакета. npm ci поможет в этом.

Answer 10

Отключить пакет-lock.json глобально

введите следующее в вашем терминале:

npm config set package-lock false

это действительно работает для меня, как магия

Answer 11

Все ответы говорят "ДА", но это также зависит от проекта, в документе говорится:

Одна из ключевых особенностей package-lock.json заключается в том, что его нельзя опубликовать, и он будет проигнорирован, если будет найден в любом месте, кроме пакета верхнего уровня.

Это означает, что вам не нужно публиковать в npm свой package-lock.json для зависимости, но вам нужно использовать package-lock.json в вашем репо, чтобы заблокировать версию вашей тестовой зависимости, построить зависимости...

Однако, если вы используете lerna для управления проектами с несколькими пакетами, вы должны поместитьpackage.json только в корне вашего репо, а не в каждом подпакете создаются с npminit. У вас получится что-то вроде этого:

.git
lerna.json
package.json
package-lock.json        <--- here
packages/a/package.json
packages/a/lib/index.js
packages/b/package.json
packages/b/lib/index.js

Answer 12

ТЛТР

Примите меры в следующих ситуациях.

---

1. Зафиксировать, если добавить новыйnpm/yarnпакеты для проекта.
2. Зафиксировать, если какие-либо изменения вpackage.jsonобновляет файл.
3. Зафиксируйте, если какая-либо версия изменяется в пакетах, nodejs, Yarn обновляется..lockфайл.

Не принимайте на себя обязательства в следующих ситуациях.

---

1. вы не кодировали и не получали обновленный файл блокировки

2. вы только что выполнили запрос и получили обновленный файл блокировки

3. только что сделал git clone и получил обновленный файл блокировки

4. вы закодировали функцию и не сделали ничего, связанного с указанными выше точками фиксации, и файл блокировки по-прежнему обновляетсяit means other dev did not push lock file during above specified commit points

Заключение

Основная цель файла блокировки заключается в том, чтоall developers&all environments&all machinesпроект, на котором установлен проект, должен иметь ULTRA ACCURATED библиотеки и версии.

Итак, по сути, есть только 3 ситуации для фиксации.

Answer 13

Я использую npm для генерации уменьшенных / увеличенных css/js и для создания javascript, необходимого на страницах, обслуживаемых приложением django. В моих приложениях Javascript запускается на странице для создания анимации, иногда выполняет вызовы ajax, работает в рамках VUE и / или работает с CSS. Если package-lock.json имеет некоторый переопределенный контроль над тем, что находится в package.json, то может потребоваться, чтобы была одна версия этого файла. По моему опыту, это либо не влияет на то, что установлено с помощью npm install, либо, если это так, на сегодняшний день не оказало негативного влияния на приложения, которые я развернул, насколько мне известно. Я не использую mongodb или другие подобные приложения, которые традиционно являются тонкими клиентами.

Я удаляю package-lock.json из репозитория, поскольку npm install создает этот файл, а npm install является частью процесса развертывания на каждом сервере, на котором выполняется приложение. Контроль версий узла и npm выполняется вручную на каждом сервере, но я осторожен, что они одинаковы.

когда npm install запускается на сервере, он изменяет package-lock.json, и если в файл, записанный репо на сервере, вносятся изменения, при следующем развертывании НЕ БУДЕТ извлекать новые изменения из источника. То есть вы не можете развернуть, потому что pull будет перезаписывать изменения, сделанные в package-lock.json.

Вы даже не можете перезаписать локально сгенерированный package-lock.json тем, что находится в репозитории (сброс мастера жесткого происхождения), так как npm будет жаловаться, когда вы будете вводить команду, если package-lock.json не отражает то, что находится в node_modules из-за npm install, тем самым нарушая развертывание. Теперь, если это указывает на то, что в node_modules были установлены несколько разные версии, еще раз, это никогда не вызывало у меня проблем.

Если node_modules нет в вашем репо (и не должно быть), то package-lock.json следует игнорировать.

Если я что-то упустил, пожалуйста, исправьте меня в комментариях, но смысл, что версия взята из этого файла, не имеет смысла. Файл package.json содержит номера версий, и я предполагаю, что этот файл используется для сборки пакетов при установке npm, а когда я его удаляю, npm install жалуется на следующее:

jason@localhost:introcart_wagtail$ rm package.json
jason@localhost:introcart_wagtail$ npm install
npm WARN saveError ENOENT: no such file or directory, open '/home/jason/webapps/introcart_devtools/introcart_wagtail/package.json'

и сборка завершается неудачно, однако при установке node_modules или применении npm для сборки js / css жалоб не возникает, если я удаляю package-lock.json

jason@localhost:introcart_wagtail$ rm package-lock.json 
jason@localhost:introcart_wagtail$ npm run dev

> introcart@1.0.0 dev /home/jason/webapps/introcart_devtools/introcart_wagtail
> NODE_ENV=development webpack --progress --colors --watch --mode=development

 10% building 0/1 modules 1 active ...

Answer 14

Да, вам следует его зафиксировать, потому что он содержит информацию о том, что было установлено, и эта информация может быть полезной — например, вы можете использовать ее в конвейерах CI/CD, выполняя в них, для достижения детерминированных сборок или когда другой разработчик хочет точно установите те же зависимости, которые вы установили черезnpm ci.

Answer 15

Передача package-lock.json в систему контроля версий исходного кода означает, что проект будет использовать определенную версию зависимостей, которая может совпадать или не совпадать с теми, которые определены в package.json. хотя у зависимости есть конкретная версия без каких-либо знаков Caret (^) и тильды (~), как вы можете видеть, это означает, что зависимость не будет обновлена ​​до самой последней версии. а npm install получит ту же версию, что и нам нужна для нашей текущей версии Angular.

Примечание: package-lock.json настоятельно рекомендуется зафиксировать его, ЕСЛИ я добавил в зависимость символы Caret (^) и Tilde (~), которые будут обновляться во время CI.

Answer 16

Мне нужно установить mongodb для node.js. но он показывает следующую ошибку.

C:\react_native_node_app\node_db_exp>узел -vv14.4.0

C:\react_native_node_app\node_db_exp>npm install mongodbnpm WARN saveError ENOENT: нет такого файла или каталога, откройте «C:\react_native_node_app\node_db_exp\package.json» npm WARN enoent ENOENT: такого файла или каталога нет, откройте «C:\react_native_node_app\node_db_exp\package.json'npm WARN node_db_exp Нет описания npm WARN node_db_exp Нет поля репозитория. npm WARN node_db_exp Нет данных README npm WARN node_db_exp Нет поля лицензии.

• [email protected] добавлено 20 пакетов от 59 участников и проверено 20 пакетов за 9,832 с.

3 пакета ищут финансирование npm fundподробности

найдено 0 уязвимостей

может ли кто-нибудь помочь в этом? Я впервые использую node и mongodb, следуя инструкциям на w3schools.com.

Answer 17

Примечание: во-первых, я не смог заставить работать предложенное ниже решение, но чувствую, что с большим знанием предмета мы сможем заставить его работать. Дайте мне знать, помогло ли это вам или моему пониманию npm-merge-driver неправильно.

Как говорят многие здесь it will cause a lot of noise or conflictв этом случае запустите:

npx npm-merge-driver install -g

А также

npx npm-merge-driver install
$ git merge my-conflicting-branch
npm WARN conflict A git conflict was detected in package-lock.json. Attempting to auto-resolve.

added 1 package in 0.077s
Auto-merging package-lock.json
Merge made by the 'recursive' strategy.
 package-lock.json | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)
$ git status
<clean>

Проверьте больше на документах здесь: https://www.npmjs.com/package/npm-merge-driver