В чем разница между npm-shrinkwrap.json и пакет-блокировка.в JSON?

С выпуск npm@5, теперь он напишет package-lock.json Если npm-shrinkwrap.json уже существует.

Я установил npm@5 глобально через:

npm install npm@5 -g

а теперь, если npm-shrinkwrap.json в:

npm install

предупреждение будет напечатано:

npm WARN read-shrinkwrap This version of npm
is compatible with lockfileVersion@1,
but npm-shrinkwrap.json was generated for lockfileVersion@0.
I'll try to do my best with it!

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

но почему для этого существует новый формат? Что может package-lock.json этого npm-shrinkwrap.json не может?

96
npm npm-shrinkwrap package-lock.json

3 ответов

файлы имеют точно такой же контент, но есть несколько различий в том, как npm обрабатывает их, описанных на сайт документы а также в файл docs в репозитории npm, который начинается с явного устранения разницы между этими двумя файлами:

  • package-lock.json никогда не публикуется в npm, тогда как npm-shrinkwrap по умолчанию
  • package-lock.json файлы, которые не находятся в пакете верхнего уровня, игнорируются, но файлы shrinkwrap принадлежность к зависимостям уважается
  • npm-shrinkwrap.json обратно совместим с версиями npm 2, 3 и 4, тогда как package-lock.json распознается только npm 5+

вы можете преобразовать существующий package-lock.json до npm-shrinkwrap.json под управлением npm shrinkwrap.

таким образом:

  • если вы не публикуете свой пакет в npm, выбор между этими двумя файлами имеет небольшое значение. Вы можете использовать package-lock.json потому что это по умолчанию и его имя понятнее для начинающих НПМ; в качестве альтернативы, вы можете использовать npm-shrinkwrap.json для обратной совместимости с npm 2-4, если вам трудно убедиться, что все в вашей команде разработчиков находятся на npm 5+. (Обратите внимание, что npm 5 был выпущен 25 мая 2017; обратная совместимость станет все менее и менее важной, чем дальше мы получим от этой даты, поскольку большинство людей в конечном итоге обновятся.)

  • если вы are публикация пакета в npm, у вас есть выбор между:

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


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

93

объяснение от разработчика NPM:

идея определенно для package-lock.json будет последним и Самый большой в технологии shrinkwrap, и npm-shrinkwrap.JSON, чтобы быть зарезервировано для тех драгоценных немногих людей, которые очень заботятся о своих библиотеках, имеющих точные node_modules -- и для людей кто хочет, чтобы CI с помощью npm@>=2 устанавливал определенное дерево без необходимости чтобы поднять его версию npm.

новый файл (пакет-замок".JSON") разделяет в основном все тот же код, тот же формат, что и npm-shrinkwrap (вы можете переименовать они между собой!). Это то сообщество, кажется поймите: "у него есть lockfile", кажется, нажимает намного быстрее с помощью люди. Наконец, наличие нового файла означало, что мы могли бы относительно низкий риск назад-compat с shrinkwrap без необходимости делать странные такие вещи, как allow-публикация, упомянутая в Родительском сообщении.

19

Я думаю, что идея состояла в том, чтобы иметь --save и shrinkwrap по умолчанию, но избегать любых потенциальных проблем с shrinkwrap, где это не было нужно. Таким образом, они просто дали ему новое имя файла, чтобы избежать конфликтов. Кто-то из npm объяснил это более подробно здесь:

https://www.reddit.com/r/javascript/comments/6dgnnq/npm_v500_released_save_by_default_lockfile_better/di3mjuk/

соответствующая цитата:

npm публикует большинство файлов в исходном каталоге по умолчанию, и люди были публикации shrinkwraps в течение многих лет. Мы не хотели нарушить совместимость. С --save и shrinkwrap по умолчанию, был большой риск того, что он случайно попадет внутрь и распространится через реестр, и в основном оказывают нашу способность обновлять deps и дедупликация... ноль.

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

11