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

158

С выпуском npm @ 5 теперь будет записываться, package-lock.jsonесли a не 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не может?

npm npm-shrinkwrap package-lock.json

— k0pernikus
источник

Ответы:

176

Файлы имеют одинаковый контент, но есть несколько различий в том, как npm обрабатывает их, описанных на сайте документации, а также в файле документов в репозитории 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 года; обратная совместимость будет становиться все менее и менее важной по мере того, как мы будем получать эту дату, поскольку большинство людей в конечном итоге будут обновляться.)
Если будут публиковать свой пакет в НПМ, у вас есть выбор между:
1. с помощью a package-lock.jsonточно записать, какие версии зависимостей вы установили, но позволяя людям, устанавливающим ваш пакет, использовать любую версию зависимостей, совместимую с диапазонами версий, определяемыми вами package.json, или
2. используя , npm-shrinkwrap.jsonчтобы гарантировать , что каждый , кто устанавливает ваш пакет получает точно такую же версию всех зависимостей
Официальная точка зрения, описанная (очень кратко) в документации, заключается в том, что вариант 1 следует использовать для библиотек (предположительно, чтобы уменьшить количество дублирования пакетов, вызываемого, когда все зависимости пакета зависят от слегка отличающихся версий одной и той же вторичной зависимости). , но этот вариант 2 может быть целесообразным для исполняемых файлов, которые будут установлены глобально.

— Марк Эмери
источник

+1 - вы можете уточнить свой второй пункт пули хотя? Какая разница между этим поведением и наличием термоусадочной пленки?

— Рис

@ На самом деле вторая пуля не имеет значения на практике, если вы не делаете что-то странное. В основном, это просто говорит , что если библиотека каким - то образом сделал опубликовать package-lock.json(что невозможно), то , если вы должны были установить эту библиотеку в качестве зависимости какой - либо другой пакет, то библиотеки package-lock.jsonбудут игнорироваться НПМ. Однако, если библиотека публикует npm-shrinkwrap.json, и вы устанавливаете библиотеку как зависимость, то вы также установите в качестве вторичных зависимостей точные версии всех зависимостей, указанных в библиотеке npm-shrinkwrap.json.

— Марк Амери

Можете ли вы добавить, что npm ciсуществует, чтобы обеспечить установку только для package-lock.jsonчтения. ( npm installмутирует package-lock.jsonвызывающую путаницу и потенциальные ошибки и не пользуется преимуществом package-lock.jsonper se.)

— k0pernikus

@ k0pernikus Я не думаю, что есть какая-то разница между тем, как npm ciобрабатывается, npm-shrinkwrap.jsonи package-lock.json- какое отношение это имеет к этому вопросу о разнице между двумя файлами? Кроме того, после прочтения: я думаю, что « npm install... не использует преимущества package-lock.json» было ложным с npm 5.4 - npm installтеперь я верю, что вы уважаете вас, package-lock если только это не будет полностью несовместимо с вашим package.json, и в этом случае последний будет иметь приоритет. (Но я немного вышел из мира JavaScript - я что-то упустил?)

— Марк Амери

Объяснение от NPM Developer :

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

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

— SeriousM
источник

Я до сих пор не понимаю разницу. Если npm-shrinkwrapдля точных node_modules .... Я предполагаю, package-lock.jsonчто блокировка менее точна? И если так, что не блокировка, которая npm-shrinkwrapблокирует?

— Дман

Вы неправильно поняли @dman. package-lock - это новая версия npm-shrinkwrap. Пакет-блокировка отключена (поэтому вы должны удалить эту функцию, потому что она включена по умолчанию), npm-shrinkwrap отключена (поэтому вы должны включить ее, потому что она не включена по умолчанию). причина, по которой они ввели пакетную блокировку, заключается в том, что 1. пользователь теперь имеет более безопасный способ работы с зависимостями, потому что он включен по умолчанию, и 2. имя подразумевает то, что он противопоставляет «сжатой упаковке». У npm-shrinkwrap были некоторые специальные настройки поведения зависимости, которых нет у package-lock. npm-shrinkwrap устарел.

— SeriousM

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

— Дман

Также пакет-lock.json навязчив. Так что это может легко вызвать конфликты scm, если вы вызовете «npm i», в то время как shrinkwrap должен быть явно сгенерирован и не вызовет конфликтов на серверах ci. Да, я могу ошибаться здесь.

— норехов

@dman "package-lock.json имеет ошибку, а npm-shrinkwrap нет" - нет, это не так. В проблеме, с которой вы связаны, нет никаких указаний; это даже не упоминает npm-shrinkwrap. Как я отмечаю в своем ответе, преобразование a package-lock.jsonв a npm-shrinkwrap.jsonбуквально выполняется путем переименования файла; они являются «тот же самый код».

— Марк Амери

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

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

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

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

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

— Коди Брумфилд
источник