个人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…