npm package-lock.json

描述

package-lock.json對于任何 npm 修改node_modules樹或package.json.?它描述了生成的確切樹，以便后續(xù)安裝能夠生成相同的樹，而不管中間依賴項更新如何。

此文件旨在提交到源存儲庫中，并用于多種目的：

• 描述依賴樹的單一表示，以便保證團隊成員、部署和持續(xù)集成安裝完全相同的依賴關系。
• 為用戶“時間旅行”到以前的狀態(tài)提供便利，?node_modules而無需提交目錄本身。
• 通過可讀的源代碼控制差異提高樹更改的可見性。
• 通過允許 npm 跳過先前安裝的包的重復元數(shù)據(jù)解析來優(yōu)化安裝過程。
• 從 npm v7 開始，鎖文件包含足夠的信息來獲得包樹的完整圖片，減少讀取package.json?文件的需要，并允許顯著的性能改進。

package-lock.json?對比?npm-shrinkwrap.json

這兩個文件具有相同的格式，并且在項目的根目錄中執(zhí)行類似的功能。

不同的是package-lock.json不能發(fā)布，如果在根項目以外的任何地方發(fā)現(xiàn)都會被忽略。

相比之下，npm-shrinkwrap.json允許發(fā)布，并從遇到的點定義依賴樹。除非部署 CLI 工具或以其他方式使用發(fā)布過程來生成生產(chǎn)包，否則不建議這樣做。

如果package-lock.json和npm-shrinkwrap.json都存在于項目的根目錄中，npm-shrinkwrap.json則將優(yōu)先并被?package-lock.json忽略。

隱藏的鎖文件

為了避免node_modules重復處理文件夾，從 v7 開始，npm 使用存在于?node_modules/.package-lock.json.?這包含有關樹的信息，node_modules如果滿足以下條件，則用于代替讀取整個層次結構：

它引用的所有包文件夾都存在于node_modules層次結構中。node_modules層次結構中不存在未在鎖定文件中列出的包文件夾。文件的修改時間至少與其引用的所有包文件夾一樣近。也就是說，隱藏的鎖文件只有在作為包樹的最新更新的一部分創(chuàng)建時才相關。如果另一個 CLI 以任何方式改變樹，這將被檢測到，隱藏的鎖文件將被忽略。

注意，它是可以手動改變內容在這樣一種方式，包文件夾的修改的時間是不受影響的封裝的。例如，如果您將文件添加到node_modules/foo/lib/bar.js，則修改時間node_modules/foo不會反映此更改。如果您在 中手動編輯文件node_modules，通常最好刪除 中的文件node_modules/.package-lock.json。

由于較舊的 npm 版本會忽略隱藏的鎖文件，因此它不包含“普通”鎖文件中存在的向后兼容性可供性。也就是說，它是lockfileVersion: 3，而不是?lockfileVersion: 2。

處理舊的鎖文件

當 npm 在包安裝過程中從 npm v6 或之前檢測到鎖文件時，它會自動更新以從node_modules樹或（在空node_modules樹或非常舊的鎖文件格式的情況下?）npm 注冊表中獲取丟失的信息。

文件格式

name

這是一個包鎖的包的名稱。這將匹配package.json.

version

這是一個包鎖的包的版本。這將匹配package.json.

lockfileVersion

一個整數(shù)版本，從1這個文檔的版本號開始，在生成 this 時使用了它的語義?package-lock.json。

請注意，npm v7 中的文件格式發(fā)生了重大變化，以跟蹤原本需要查看node_modulesnpm 注冊表的信息。npm v7 生成的鎖文件將包含?lockfileVersion: 2.

未提供版本：來自 npm v5 之前的 npm 版本的“古老”收縮包裝文件。1：npm v5 和 v6 使用的鎖文件版本。2：npm v7 使用的鎖文件版本，向后兼容 v1 鎖文件。3：npm v7 使用的鎖文件版本，沒有向后兼容性可供性。這用于隱藏的鎖文件?node_modules/.package-lock.json，一旦不再支持 npm v6，很可能會在 npm 的未來版本中使用。npm 將始終嘗試從鎖定文件中獲取它可以獲取的任何數(shù)據(jù)，即使它不是它旨在支持的版本。

packages

這是一個將包位置映射到包含有關該包的信息的對象的對象。

根項目通常以 鍵列出""，所有其他包都以它們從根項目文件夾的相對路徑列出。

包描述符具有以下字段：

• 版本：找到的版本?package.json
• 已解析：實際解析包的位置。對于從注冊表獲取的包，這將是一個指向 tarball 的 url。對于 git 依賴項，這將是帶有 commit sha 的完整 git url。在鏈接依賴的情況下，這將是鏈接目標的位置。
• 完整性：?在此位置解包的工件的sha512或sha1?標準子資源完整性字符串。
• 鏈接：一個標志，表明這是一個符號鏈接。如果存在，則不指定其他字段，因為鏈接目標也將包含在鎖定文件中。
• dev, optional, devOptional：如果包嚴格地是devDependencies樹的一部分，則為?dev真。如果它嚴格是optionalDependencies樹的一部分，optional則將被設置。如果它既是一個dev依賴性和一個optional非開發(fā)依賴的相關性，然后devOptional將被設置。（optional依賴項的dev依賴項將同時設置dev和optional設置。）
• inBundle：指示包是捆綁依賴項的標志。
• hasInstallScript：一個標志，以表明該封裝具有preinstall，?install或postinstall腳本。
• hasShrinkwrap：一個標志，表明包有一個?npm-shrinkwrap.json文件。
• bin、license、engines、dependencies、optionalDependencies：來自的字段?package.json

依賴

用于支持使用lockfileVersion: 1.?這是包名到依賴對象的映射。因為對象結構是嚴格分層的，符號鏈接依賴在某些情況下很難表示。

如果某個packages部分存在，npm v7 會完全忽略該部分，但會使其保持最新狀態(tài)以支持在 npm v6 和 npm v7 之間切換。

依賴對象具有以下字段：

• version：根據(jù)包的性質而變化的說明符，可用于獲取它的新副本。
  • 捆綁依賴項：無論來源如何，這是一個純粹用于提供信息目的的版本號。
  • 注冊表源：這是一個版本號。（例如，1.2.3）
  • git 來源：這是一個 git 說明符，具有已解決的 committish。（例如，?git+https://example.com/foo/bar#115311855adb0789a0466714ed48a1499ffea97e）
  • http tarball 來源：這是 tarball 的 URL。（例如，?https://example.com/example-1.3.0.tgz）
  • 本地 tarball 源：這是 tarball 的文件 URL。（例如?file:///opt/storage/example-1.3.0.tgz）
  • 本地鏈接源：這是鏈接的文件 URL。（例如?file:libs/our-module）
• 完整性：?在此位置解包的工件的sha512或sha1?標準子資源完整性字符串。對于 git 依賴項，這是提交 sha。
• 已解析：對于注冊表源，這是相對于注冊表 URL 的 tarball 路徑。如果 tarball URL 與注冊表 URL 不在同一臺服務器上，那么這是一個完整的 URL。
• bundled：如果為 true，則這是捆綁的依賴項，將由父模塊安裝。安裝時，這個模塊會在提取階段從父模塊中提取出來，而不是作為單獨的依賴項安裝。
• dev: 如果為真，那么這個依賴要么是頂層模塊的開發(fā)依賴，要么是一個的傳遞依賴。對于既是頂級開發(fā)依賴又是頂級非開發(fā)依賴的傳遞依賴的依賴，這是錯誤的。
• 可選：如果為真，那么這個依賴要么是頂層模塊的可選依賴，要么是一個的傳遞依賴。對于既是頂層的可選依賴又是頂層非可選依賴的傳遞依賴的依賴，這是錯誤的。
• 要求：這是模塊名稱到版本的映射。這是此模塊所需的所有內容的列表，無論它將安裝在哪里。版本應該通過正常匹配規(guī)則匹配我們dependencies或比我們更高級別的依賴項。
• 依賴：這個依賴的依賴，和頂層完全一樣。