個人package-lock.json被誰改了？

豆皮粉兒們，你們好呀。一轉眼又陪伴你們來到了不負春光和時行，人間最美的四月天。

做者：羯磨

你們在提交代碼時，是否會常常遇到提示package-lock.json有莫名其妙變更的提示？下面就跟這篇文章一塊兒來一探究竟吧。

介紹

以前咱們項目常常會出現執行npm i後 package-lock.json被更改的問題，可是常常是咱們以爲不該該出現被更改的狀況而被更改了，看了一下package-locks | npm Docs官方文檔，並結合實踐分析了一下可能的緣由，下面的內容都是針對 npm@7 如下的狀況而言的，npm@7 更新了 lockfiles 的版本，具體會在別的文章中介紹

package-lock.json 生成邏輯

npm@5 之後 npm 會根據 package.json 生成 lockfiles 文件，目的就是爲了保證生產和線上編譯或者團隊開發時你們生成 node_modules tree是一致的，可是即便是這樣不一樣版本的 npm 對於 lockfiles 的處理邏輯是不一樣的npm install 生成的package-lock.json是什麼文件?有什麼用? - 知乎。

5.0.x

該版本下 npm 忽略 package.json 的變化，只會根據 lockfiles 下載 node_modules

5.1.0 - 5.4.2

npm 又變成了會錯誤的忽略 lockfiles 去下載 node_modules

5.4.2

這版的邏輯我以爲是最自洽的 github.com/npm/npm/iss…

If you have a package.json and you run npm i we generate a package-lock.json from it.

If you run npm i against that package.json and package-lock.json, the latter will never be updated, even if the package.json would be happy with newer versions.

If you manually edit your package.json to have different ranges and run npm i and those ranges aren't compatible with your package-lock.json then the latter will be updated with version that are compatible with your package.json. Further runs of npm i will be as with 2 above.

總結起來就是若是咱們修改了 package.json 裏包的版本，若是新的包的版本和與 lockfiles 裏包的版本對照是不符合semver規範的，那麼，lockfiles 裏對應的 version 就會被更新。

package-lock.json 生成的邏輯

只是簡單描述一下 lockfiles 生成的邏輯 咱們如今有三個 package,

// package lock-test
{
    "name": "lock-test",
    "dependencies": {
        "A": "^1.0.0"
    }
}

// package A
{
  "name": "A",
  "version": "1.0.0",
  "dependencies": {
    "B": "^1.0.0"
  }
}

// package B
{
  "name": "B",
  "version": "1.0.0",
  "dependencies": {
    "C": "^1.0.0"
  }
}

// package C
{
  "name": "C",
  "version": "1.0.0"
}
複製代碼

在這種狀況下 package-lock.json, 會生成相似下面鋪平的結構

// package-lock.json
{
  "name": "lock-test",
  "version": "1.0.0",
  "dependencies": {
    "A": {
      "version": "1.0.0"
    },
    "B": {
      "version": "1.0.0"
    },
    "C": {
      "version": "1.0.0"
    }
  }
}
複製代碼

簡單說會以當前 package.json 包裏對應包符合要求的最新版記錄在 lockfiles 裏，若是後續不管是直接依賴的 A 發版，或者間接依賴的B, C 發版，只要咱們不動 package.json, lockfiles 都不會從新生成。

A 發佈了新版本 1.1.0，雖然咱們 package.json 寫的是 ^1.0.0 可是由於 lockfiles 的存在，npm i 並不會自動升級，咱們能夠手動運行 npm i A@1.1.0 來實現升級。由於 1.1.0 版本與lockfiles 裏記錄的 A@1.0.0 是不一致的，所以會更新 lockfiles 裏的 A 的版本爲 1.1.0。

B 發佈了新版本 1.0.1, 1.0.2, 1.1.0, 此刻若是咱們不作操做是不會自動升級 B 的版本的，但若是此刻 A 發佈了 1.1.1，雖然並無升級 B 的依賴，可是若是咱們項目裏升級 A@1.1.1，此時 lockfiles 裏會把 B 直接升到 1.1.0 ,由於此刻^1.0.0的最新版本就是 1.1.0。

通過這些操做後 package.json 變成

// package lock-test
{
    "dependencies": {
        "A": "^1.1.0"
    }
}
複製代碼

對應的package-lock.json文件

{
  "name": "lock-test",
  "version": "1.0.0",
  "dependencies": {
    "A": {
      "version": "1.1.0"
    },
    "B": {
      "version": "1.1.0"
    },
    "C": {
      "version": "1.0.0"
    }
  }
}
複製代碼

這個時候咱們將 B加入咱們項目的依賴, B@^1.0.0，package.json以下

{
    "dependencies": {
        "A": "^1.1.0",
        "B": "^1.0.0"
    }
}
複製代碼

咱們執行這個操做後，lockfiles 並無被改變，由於如今 lockfiles 裏 B@1.1.0 知足 ^1.0.0 的要求

可是若是咱們將 B 的版本固定到 2.x 版本, lockfiles 就會發生改變

{
    "dependencies": {
        "A": "^1.1.0",
        "B": "^2.0.0"
    }
}
複製代碼

由於存在了兩個衝突的B版本，package-lock.json文件會變成以下形式

{
  "name": "lock-test",
  "version": "1.0.0",
  "dependencies": {
    "A": {
      "version": "1.1.0",
      "dependencies": {
        "B": {
          "version": "1.1.0"
        }
      }
    },
    "B": {
      "version": "2.0.0"
    },
    "C": {
      "version": "1.0.0"
    }
  }
}
複製代碼

由於 B 的版本出現了衝突，npm 使用嵌套描述了這種行爲

咱們實際開發中並不須要關注這種生成的算法邏輯，咱們只須要了解，lockfiles 的生成邏輯是爲了可以精準的反映出咱們 node_modules 的結構，並保證可以這種結構被還原。

package-lock.json 可能被意外更改的緣由

1. 新增或者刪除了一些包，可是沒有及時 install

咱們能夠想象出現這樣一種場景，a 同窗給 package.json 添加了一個 package，可是沒有執行 npm install，代碼被 push 上去後，b 同窗執行 npm i，就會發現 lockfiles 被更改了

2. 挪動了包的位置

將部分包的位置從 dependencies 移動到 devDependencies這種操做，雖然包未變，可是也會影響 lockfiles，會將部分包的 dev 字段設置爲 true

3. registry 的影響

通過實際使用發現，若是咱們 node_modules 文件夾下的包中下載時的的 registry 與 lockfiles 中包即便 version 相同，可是registry是不一樣，執行 npm i 時也會修改。

可能還存在其餘的緣由，可是 lockfiles 是不會平白無故被更改的，必定是由於 package.json 或者 node_modules 被更改了，由於 正如上面提到的 lockfiles 爲了可以精準的反映出咱們 node_modules 的結構

開發的建議

目前來看，npm install 是足夠可靠的，他能保證根據 lockfiles 還原出開發時的 node_modules，可是爲了防止出現剛剛提到的意外狀況，除非涉及到對包的調整，其餘狀況下建議使用 npm ci 來安裝依賴，會避免異常的修改 lockfiles，持續集成工具中更推薦是用 npm ci，保證構建環境的準確性，npm i 和 npm ci 的區別能夠參考官方文檔 npm-install | npm Docs，npm-ci | npm Docs

---

data-數據平臺承載了公司旗下包括抖音、今日頭條在內的全部產品的數據採集、加工、存儲、查詢、治理工做，支撐從一線產品運營到高層管理者等衆多角色的平常工做與關鍵決策，用「平臺化」的手段，實現「數據驅動智能」的願景。其中前端團隊是數據平臺的重要組成部分。

數據平臺前端團隊，在公司內負責風神、TEA、Libra、Dorado等大數據相關產品的研發。咱們在前端技術上保持着很是強的熱情，除了數據產品相關的研發外，在數據可視化、海量數據處理優化、web excel、WebIDE、私有化部署、工程工具都方面都有不少的探索和積累。

歡迎投遞簡歷 juejin.cn/team/693081…