如何确保package-lock.json锁定依赖版本，防止自动更新？

我太懂这种间接依赖偷偷更新导致构建崩掉的痛苦了——排查起来绕来绕去，真的耗精力。针对你问的怎么让package-lock.json牢牢锁住版本，避免重新安装或时间推移后自动“漂移”，我整理了几个实用的方法和注意事项：

1. 先搞清楚package-lock.json的本质 #

首先要明确：package-lock.json本身的设计目标就是精确锁定所有依赖（包括间接依赖）的版本，只要操作得当，它能保证每次执行npm install都安装完全一致的依赖版本。所谓“失效”大多是因为操作方式不对。

2. 避免触发自动更新的操作 #

• 别用npm update命令：这个命令会主动把依赖更新到package.json版本范围内的最新版，同时修改package-lock.json，完全违背了锁定的初衷。
• 不要修改package.json版本范围后直接npm install：如果你的依赖用了^或~这类前缀，修改范围后执行安装，npm会拉取新的匹配版本并更新锁文件。
• 检查npm配置：执行npm config get package-lock，如果返回false说明锁文件被禁用了，赶紧设置回来：

  npm config set package-lock true
  

3. 强化锁定的额外手段 #

如果怕还是有意外，这些方法能进一步加固：

• 用npm ci替代npm install：npm ci（clean install的缩写）会严格按照package-lock.json的内容安装，完全忽略package.json的版本范围，甚至如果锁文件和package.json不匹配会直接报错。这是CI/CD环境的最佳实践，本地开发用它也能彻底避免版本漂移。
• 强制锁定间接依赖：针对你遇到的prettier这种间接依赖问题，可以在package.json里加resolutions字段强制指定版本（需要npm 5.4+或使用yarn）：

  {
    ...
    "resolutions": {
      "prettier": "1.12.0"
    },
    ...
  }
  

  添加后执行npm install，package-lock.json就会把prettier牢牢锁在1.12.0，不管它的上层依赖要求什么版本范围。

4. 锁文件维护的最佳实践 #

• 一定要把package-lock.json提交到Git仓库：这是团队协作和CI环境保持依赖一致的核心，确保所有人用的都是同一个锁文件。
• 别随便删package-lock.json：除非你确实需要彻底更新所有依赖，否则删除后重新生成很可能再次引入不兼容版本。

针对你提供的package.json示例，建议先添加resolutions字段锁定prettier到1.12.0，执行npm install更新锁文件后提交到仓库，之后用npm ci来安装依赖，就能彻底杜绝这个问题再次出现了。

内容的提问来源于stack exchange，提问作者Andrea Epifani