是什麼NPM-shrinkwrap.json和包lock.json之間的區別？

隨着release of [email protected]，現在會寫package-lock.json除非npm-shrinkwrap.json已經存在。是什麼NPM-shrinkwrap.json和包lock.json之間的區別？

我安裝NPM @ 5全球範圍內通過：

npm install [email protected] -g

而現在，如果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不能？

來源

2017-05-30 k0pernikus

該文件具有完全相同的內容，但也有差異NPM如何處理他們一把，在a docs file in the npm repo that starts by explicitly addressing the difference between these two files上the docs site描述，也：

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只承認。

這樣：

如果不發佈你的包到故宮，這兩個文件之間的選擇是無關緊要的。你可能希望使用package-lock.json，因爲它是默認的，它的名字更清晰的npm初學者;或者，如果您難以確保開發團隊中的每個人都使用npm 5+，則您可能希望使用npm-shrinkwrap.json向後兼容npm 2-4。（請注意，npm 5於2017年5月25日發佈;向後兼容性將越來越不重要，因爲大多數人最終都會升級。）
如果您的是將您的軟件包發佈到npm ，您有以下兩種選擇：使用package-lock.json準確地記錄您安裝的依賴關係的版本，但允許人們安裝軟件包使用的依賴關係的任何版本與您package.json所規定的版本範圍兼容
1. ，或
2. 使用npm-shrinkwrap.json以保證大家誰安裝你的軟件包被正是所有依賴
在文檔中描述的（非常簡潔）的官方觀點認爲，選擇1應該用於庫（大概是爲了同一版本減少大量程序包的依賴關係導致的程序包重複數量都取決於相同次要依賴關係的稍微不同的版本），但是對於即將在全局安裝的可執行程序，該選項2可能是合理的。

來源

2017-09-09 16:03:53

+1 - 你能澄清你的第二個重點嗎？這種行爲與npm-shrinkwrap有什麼區別？ – Rhys

@Rhys第二顆子彈在實踐中無關緊要，除非你做了奇怪的事情。基本上，它只是說如果一個庫以某種方式*發佈了一個'package-lock.json'（這是不可能的），那麼如果你想將該庫作爲其他包的依賴來安裝，那麼該庫的'package -lock.json'會被NPM忽略。但是，如果庫發佈了'npm-shrinkwrap.json'，並且將庫作爲依賴項安裝，那麼您還將*作爲輔助依賴項安裝在庫的'npm-shrinkwrap'中指定的所有依賴項的*精確版本* .json'。 –

我認爲這個想法是有--save和拆封默認情況下發生，但避免與拆封發生在那裏沒有任何希望的潛在問題。所以，他們給了它一個新的文件名以避免任何衝突。從NPM有人解釋它更徹底這裏：

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

相關報價：

NPM發佈的大多數文件源目錄中的默認，並人們一直在出版shrinkwraps多年。我們不想中斷兼容性。隨着--save和拆封默認情況下，有它的一個巨大風險意外使得它在通過註冊表傳播，基本上使我們的更新DEPS和重複數據刪除能力...空。

因此，我們選擇了一個新的名字。我們選擇了一種突然出現的全新名稱。新的鎖定文件股基本上都是相同的代碼，該完全一樣的格式

來源

2017-05-30 23:22:24 cbrumsin

您能否在您的答案中包含鏈接內容的相關部分？您可以將其標記爲報價。基本上，答案應該是獨立的，不需要遵循鏈接。 – k0pernikus

Explanation from NPM Developer：

的想法絕對是包lock.json是在拆封技術的最新和最偉大的和NPM-shrinkwrap.json是那些珍貴的少數人在那裏誰在乎保留非常關於有一個確切的node_modules他們的圖書館 - 爲人們誰想要CI使用NPM @> = 2，安裝一個特定的樹沒有到b ump它的npm版本。

新鎖文件（「包lock.json」）的股票基本都是相同的代碼，完全一樣的格式爲NPM-拆封（您可以重命名他們彼此之間！）。這也是一些社會似乎理解：「它有一個鎖文件」似乎單擊具有人如此之快。最後，有一個新的文件意味着我們可以有相對低風險向後COMPAT與拆封，而不必做奇怪的事情像父帖子中提到的允許出版物。

來源

2017-06-02 08:10:16 SeriousM

我仍然不清楚差異。如果'npm-shrinkwrap'確切地用於node_modules ....我假設'package-lock.json'鎖定的不是精確的？如果是這樣，那麼'npm-shrinkwrap'是否鎖定了什麼不鎖定？ – dman

你錯了@dman。包鎖是npm-shrinkwrap的新版本。 package-lock是選擇退出（因此它必須刪除該功能，因爲它的默認啓用），npm-shrinkwrap是選擇加入（所以你必須啓用它，因爲它不包括我的默認）。他們引入package-lock的原因是：1.用戶現在有了一種保存方式來處理依賴關係，因爲它默認啓用並且2。這個名字暗示了它是「反包裹」的反對意見。 npm-shrinkwrap具有一些特殊的依賴性行爲設置，它們現在沒有package-lock。 npm-shrinkwrap現在已經過時。 – SeriousM

這是不正確的。通過說包鎖是npm-shrinkwrap的新版本，你說這是一個替代品。 npm-shrinkwrap不被棄用，並且與package-lock.json有所不同。此外，package-lock.json [有一個bug]（https://github.com/npm/npm/issues/17091），而npm-shrinkwrap不會...因此強調更多，因此它們不是相同的代碼。 – dman

是什麼NPM-shrinkwrap.json和包lock.json之間的區別？

回答

相關問題