返回知识库

工程与栈 · 开发基础

包管理器Package Manager

包管理器读清单里的范围,再靠锁文件钉死精确版本和整棵树,这样大家装到同一套。

先认出这两份文件,再决定谁说了算

下面就是清单和锁文件:默认范围 ^18.2.0 对齐精确 18.2.0。只改范围不带锁,对不上也写在同一对文件上。

周末市集店 · 依赖文件范围与精确对齐
package.json^18.2.0

想要的范围

package-lock.json18.2.0

实际钉死的版本

范围与精确对齐范围和精确版本长在文件上。

原因:清单写允许的范围,锁文件钉死这次真正装到的版本。下一步:点「改范围不带锁」,看两份文件会不会各说各的。

知识点:清单写范围,锁文件钉精确

两份文件上的数字已经演示了分工,这里只命名四条。

  • 清单:写下想要的范围,比如 ^18.2.0 允许补丁和次版本。
  • 锁文件:记下这次真正装到的精确版本和整棵树。
  • 安装:包管理器读这两份文件,从仓库取包,填进 node_modules。
  • 离开后要盯:lockfile 进仓;全项目只用一种包管理器。

什么时候用、怎么用

clone、加包、CI 还原时都走包管理器;不要手拷 node_modules。

  • 信号:别人装出来版本不同、CI 和本地对不上、清单改了锁没动。
  • 适用:还原依赖、新增包、冻结安装。
  • 不适用:改业务代码本身——包管理器不管你的函数对不对。
  • 最短路径:清单写范围 → 锁文件进仓 → clone 后按锁还原。

正反例:同一对依赖文件

目标都是装到 React 18,只改锁文件在不在。

正例范围和锁一起提交

两份文件对齐。数字长在文件上。

反例只改清单范围,不带锁

一份写 19,一份还停在 18。失败写在物件上。

快速自测

package.json 写 ^18.2.0,为什么还要提交 package-lock.json?

继续查证

术语的技术定义和行为以这些一手或权威资料为准。

下一步学

和本知识点经常一起出现的概念。