it-swarm.com.ru

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

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

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

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

978
rink.attendant.6

Да, 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 будет полностью проигнорирован.

1195
vine77

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

90
xer0x

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

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

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

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

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

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

С уважением.

29
Deunz

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

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

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

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

Чтобы игнорировать package-lock.json в diff для всего репозитория (каждый, кто его использует), вы можете добавить это в .gitattributes:

package-lock.json binary
yarn.lock binary

Это приводит к тому, что diff-файлы показывают, что "Двоичные файлы a/package-lock.json и b/package-lock.json различаются при каждом изменении файла блокировки пакета. Кроме того, некоторые службы Git (в частности, GitLab, но не GitHub) также исключают эти файлы (не более 10 тыс. строк изменено!) из различий при просмотре онлайн при этом.

24
Raza

Да, вы можете зафиксировать этот файл. Из официальные документы npm :

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

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

15
Bablu Singh

Да, вы должны зафиксировать package-lock.json.

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

Один из самых больших недостатков команды npm install заключается в том, что она может изменять код package-lock.json, тогда как npm ci использует только версии, указанные в файле блокировки, и выдает ошибку, если package-lock.json и package.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} и передайте измененный package-lock.json. (Если обновление не удалось, вы можете вернуться к последнему действующему package-lock.json.)


Кому цитата из npm doc :

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

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

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

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

2
k0pernikus

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

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

npm config set package-lock false

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

1
Balogun Ridwan Ridbay

Я использую 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, и если в файле, записанном репо на сервере, есть изменения, следующее развертывание НЕ ДОЛЖНО извлекать новые изменения из Origin. То есть вы не можете развернуть, потому что pull будет перезаписывать изменения, сделанные в package-lock.json.

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

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

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

[email protected]:introcart_wagtail$ rm package.json
[email protected]: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

[email protected]:introcart_wagtail$ rm package-lock.json 
[email protected]:introcart_wagtail$ npm run dev

> [email protected] dev /home/jason/webapps/introcart_devtools/introcart_wagtail
> NODE_ENV=development webpack --progress --colors --watch --mode=development

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

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

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

Плюсы: -

  • У всех в проекте будет одна и та же версия пакета, все что вам нужно сделать, это сделать

    установка npm

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

Минусы: -

  • Это может заставить вас тянуть запросы выглядеть ужасно :)
0
Nikhil Mohadikar