В чем разница между npm-shrinkwrap.json и package-lock.json?

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

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

npm install [email protected] -g

И теперь, если a npm-shrinkwrap.json найден во время:

npm install

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

npm WARN read-shrinkwrap This version of npm
is compatible with [email protected],
but npm-shrinkwrap.json was generated for [email protected]
I'll try to do my best with it!

Итак, мой прием - заменить термоусадочную пленку на package-lock.json.

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

Ответы

Ответ 1

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

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

  • Если вы публикуете свой пакет до числа нпм, у вас есть выбор между:

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


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

Ответ 2

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

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

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

Ответ 3

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

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

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

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

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