关于node.js:npm的依赖与版本

3次阅读

共计 2906 个字符,预计需要花费 8 分钟才能阅读完成。

npm 的依赖与版本

在日常开发中咱们应用中心化的 package.json 配置文件来保护我的项目的配置信息(比方名称、版本、许可证等元数据)以及依赖模块

依赖类型

目前反对以下 5 种

  • dependencies
  • devDependencies
  • peerDependencies
  • optionalDependencies
  • bundledDependencies/bundleDependencies

示例

{
  "name": "quanerp-pc-v4",
  "version": "4.0.0",
  "private": true,
  "dependencies": {
    "react": "^16.13.0",
    "rxjs": "^6.5.4"
  },
  "devDependencies": {
    "cross-env": "^7.0.2",
    "eslint": "^6.8.0",
    "mockjs": "^1.1.0",
  },
  "peerDependencies": {},
  "optionalDependencies": {},
  "bundledDependencies": [],}

dependencies

运行我的项目的依赖,打包公布后执行所须要的

npm install packageName --save
# 或者
npm install packageName -S

devDependencies

开发模式下的依赖,只利用于开发环境,打包后的文件中不蕴含

npm install packageName --save-dev
# 或者
npm install packageName -D

peerDependencies

等同(伙伴)依赖

第一次见到的时候我也懵懵的,从字面意思上很难了解

它的作用咱们来举个栗子阐明

我写了个 npm 包 vue-element-utils 它的作用是对 element-ui 做了一些自定义指定的拓展工具,如果我在没有下载安装 element-ui 之前就应用那么就会报错。

这里咱们给 peerDependencies 退出 element-ui,它在下载时会判断以后依赖中是否有 element-ui 如果没有则 将申明的依赖装置进来 ,如果有则 疏忽 peerDependencies 中的申明

还能够解决外围依赖库被反复下载的问题。

npm v3 中移除了peerDependencies,外部做了优化,将依赖的树形构造做了扁平化解决。

npm v3 中,依赖树的生成会尽量的扁平,相应 peerDependencies 的行为有所变动。peerDependencies 中申明的依赖,如果我的项目没有显式依赖并装置,则不会被 npm 主动装置,转而输入 warning 日志

optionalDependencies

如果一个依赖模块能够被应用,同时你也心愿在该模块找不到或无奈获取时 npm 持续运行,你能够把这个模块依赖放到 optionalDependencies 配置中。这个配置的写法和 dependencies 的写法一样,不同的是这里边写的模块装置失败不会导致 npm install 失败。

留神点:optionalDependencies中的配置会笼罩 dependencies 中的配置,最好只在一个中央写。

bundledDependencies/bundleDependencies

打包依赖,是一个蕴含依赖包名的数组对象,在公布时会将这个对象中的包打包到最终的公布包里

执行 npm pack 时,将数组中的申明打包进指标包中

依赖版本

依赖天堂

艰深而言,“依赖天堂”指开发者装置某个软件包时,发现这个软件包里又依赖不同特定版本的其它软件包。随着零碎性能越来越简单,依赖的软件包越来越多,依赖关系也越来越深,这个时候可能面临版本控制被锁死的危险。

因而,Github 起草了一个具备指导意义的,对立的版本号示意规定,称为语义化程序版本 Semantic Versioning 简称 semver。该规定规定了版本号如何示意,如何减少,如何进行比拟,不同的版本号意味着什么

后行版本

  • alpha: 外部版本
  • beta: 公测版本
  • rc: 即 Release candidate 正式版本的候选版本

node-semver

npm 和 yarn 中对于依赖库版本的解析也是听从语义化程序版本标准的,同时减少了版本解析的灵便度,基于 node-semver 引入了operator

Comparators 比拟符

默认为=

comparator description
< 例如 <2.0.0,指向 小于 2.0.0 的版本
<= 例如 <=2.0.0,指向 小于等于 2.0.0 的版本
> 例如 >2.0.0,指向 大于 2.0.0 的版本
>= 例如 >=2.0.0,指向 小于等于 2.0.0 的版本
= 例如 =2.0.0,指向 等于 2.0.0 的版本

Intersections 交加符

应用空格来连贯两个比拟符,匹配在交加内的版本号。

例如 vue:>1.0.0 <=1.2.0,示意匹配 vue 版本处于区间 (v1.0.0, v1.2.0](数学示意[ 蕴含,(不蕴含,上面都用这种形式示意)

Unions 并集符

应用 || 来连贯两个比拟符,匹配在并集内的版本号。

例如vue:<1.0.0 || >=2.0.0,示意 vue 版本处于区间 [v0.0.0, v1.0.0) 和 [v2.0.0, 正无穷]

Pre-release tags 后行版本号

comparator 中的版本号蕴含后行版本号时,无论 comparator 的类型是什么,只能匹配同 主版本号. 此版本号. 订正号

例如 >=3.1.1-beta.3 只能匹配到区间 [v3.1.1-beta.3, v3.1.2)

X-Ranges 通配符

应用字符 Xx* 来取代版本中的数字,示意本段都能够匹配

例如

  • *等价于>=0.0.0
  • 2.x等价于>=2.0.0 <3.0.0
  • 3.1.x等价于>=3.1.0 <3.2.0

独自申明版本号时,空白版本段应用 x 来填充,例如:

  • 空格 = *
  • 2 = 2.x.x
  • 2.1 = 2.1.x

Tilde Ranges~

次版本号不为空时,匹配范畴只蕴含 订正号变动

主版本号不为空,次版本号为空,匹配范畴只蕴含 次版本号变动

  • ~2.1.1 = >=2.1.1 <2.1.2
  • ~2.1 = >=2.1.0 <2.2.0
  • ~2 = >=2.0.0 <3.0.0
  • ~2.1.1-beta.2 = >=2.1.1-beta.2 <2.1.1
  • ~0 = >=0.0.0 <1.0.0

Caret Ranges^

匹配与申明中第一个非 0 版本段数字雷同的版本

  • ^3.1.3 = >=3.1.3 <4.0.0
  • ^0.4.2 = >=0.4.2 <0.5.0
  • ^0.0.3 = >=0.0.3 <0.0.4

其它版本类型

npm yarn 还反对扩大的版本号申明来反对 git、github 等:

  • http://....: 指定一个可下载的 url
  • git url: 指向一个 git 我的项目门路
  • user/repo: 指定 github 上某个用户的某个我的项目
  • tag: 指向一个 tag commit,倡议 tag 名字不要以单词 v 结尾,防止与版本号混同
  • file:path/to/local/file: 指向本地环境的文件

下面的 git urluser/repo 均反对 commit-ish 作为后缀来指向某次提交、某个 tag 或某个分支

参考资料

  • 浅谈 npm 的依赖与版本
  • Semver(语义化版本号)扫盲
  • 你须要晓得的几类 npm 依赖包治理
正文完
 0