npm的版本管理

2022-12-19  本文已影响0人  路耀广的前端微博

一个依赖包的package.json是对一个项目的描述,其中dependenciesdevDependencies表示依赖包所需的依赖列表。

dependencies与devDependencies的区别

安装依赖包可以使用

// 安装在dependencies下
npm install xxx --save | npminstall -S  
// 安装在devDependencies下
npm install xxx --save-dev  | npm install -D

一句话概括就是:dependencies安装生产模式下所需的依赖,devDependencies安装开发模式下所需的依赖。
比如:
lodash,jquery,element-ui等,在我们生产环境上需要,所以要安装在dependencies下。
而eslint,webpack,sass-loader等,只在开发环境中使用,生产环境并不需要这些东西,所以就放在devDependencies下。
但是,作为前端的打包,devDependencies下安装的lodash等也会被打包到bundle中,也就是说在线上也是可以使用的。而nodejs的依赖,由于没有打包的概念,所以生产环境去install依赖时,就不会安装devDependencies下的依赖包,这一点十分重要。

版本语义化 semver

版本号

一个包的版本遵循主版本号次版本号,修订号并且版本号递增的原则。

先行版本

依赖版本号

 `^2.2.1` 对应主版本号为 2,不小于 `2.2.1` 的版本号,比如 `2.2.1`、`2.2.2`、`2.3.0` ,主版本号固定
// 当该依赖有最新版本时(eg:2.3.3),npm install 会安装最新的依赖
 `~2.2.1` 对应主版本号为 2,次版本号为 2,不小于 `2.2.1` 的版本号,比如 `2.2.1、2.2.2`,主版本号和次版本号固定
 >2.1
//注意使用 `-` 的时候,必须两边都有空格。
 1.0.0 - 1.2.0
^2 < 2.2 || > 2.3
 *`对应所有版本号
 3.x`对应所有主版本号为 3 的版本号

node_modules依赖历史变迁

嵌套式结构

在npm早期版本,npm处理依赖的方式是以递归的形式,严格按照package.json结构来安装各自的node_modules。直到子依赖包不存在依赖其他模块才停止。


image.png

优点:
这种方式的结构清晰且一一对应。

缺点:

  1. 而且不同层级的以来中,可能引用的是同以模块却被安装多次,导致大量冗余。
  2. 层级嵌套非常之深,在windows系统下,文件路径长度最大限制为260个字符,层级嵌套过深可能导致不可预知的问题。

扁平化结构

为了解决以上问题,npm在3.x版本将结构优化为扁平结构。
即安装模块时,不管其是直接依赖还是子依赖的依赖,优先将其安装在 node_modules 根目录。


image.png

依赖模块查找流程:

  1. 在当前模块路径下搜索
  2. 在当前模块的node_modules下搜索
  3. 在上级模块的node_modules下搜索
    ....
  4. 直到搜索到根路径中的node_modules
    如果版本发生冲突,比如my-app依赖c@1.0,0版本,a模块依赖c@2.0.0版本,而b模块依赖了c@3.0.0版本。


    image.png

packge-lock.json

为了解决 npm install 的不确定性问题,在 npm 5.x 版本新增了 package-lock.json 文件,而安装方式还沿用了 npm 3.x 的扁平化的方式。
package-lock.json的requiresdependencies
并不是所有的子依赖都有 dependencies 属性,只有子依赖的依赖和当前已安装在根目录的 node_modules 中的依赖冲突之后,才会有这个属性。

上一篇下一篇

猜你喜欢

热点阅读