阅读 230

npm基础回顾

概述

  • npm是什么
  • 配置
  • npm install
  • 版本号规则
  • 安装过程
  • package.lock.json
  • script生命周期
  • 常见问题

npm是什么

是用nodejs写的包管理生态系统

  • 网站 www.npmjs.com/
  • 注册表(npm数据库,60W+package)
  • cli工具(命令行)

npm配置

环境变量

windows 安装完node通常会自动设置环境变量PATH

NODE_PATH = XXX\Node\nodejs
PATH = %NODE_PATH%\;%NODE_PATH%\node_modules;%NODE_PATH%\node_global;
复制代码

如果不配置呢?

error:node不是内部或外部命令,也不是可运行的程序 或批处理文件。

npm配置项

查看npm配置

npm config ls 或 npm config list
复制代码

image

上面同样列举了npmrc(npm用户配置文件)的地址

这里面核心的是三项

  • 当前的用户信息(username、email...)
  • registry - 镜像地址,npm包的下载源(通常会修改为淘宝镜像或者私服镜像)
  • prefix - 全局安装目录

修改全局安装目录

npm config set prefix "F:\office_software\nodejs\xxx_global"
复制代码

修改镜像地址(推荐使用nrm进行多镜像管理)

npm config set registry "https://registry.npm.taobao.org"
复制代码

另外一个配置就是npm缓存的目录

$ npm config get cache
C:\Users\Administrator\AppData\Roaming\npm-cache
复制代码

npm-cache存放下载包的缓存(对应sha1计算后的内容也在里面)

修改npm缓存目录

npm config set cache "F:\office_software\nodejs\xxx_cache"
复制代码

npm install

安装操作

npm install 或 npm i

这两个命令是一样的,一个全写一个简写

npm install 或 npm i
复制代码

npm会根据package.json配置文件中的依赖配置下载安装到项目下的node_modules目录

-g 或 -global

npm i -g XXX
复制代码

全局安装,安装后的包位于系统预设目录下

image

这样就安装在了C:\Users\Administrator\AppData\Roaming\npm\node_modules目录下

-S 或 --save

安装的包将写入package.json里面的dependencies,dependencies:生产环境需要依赖的库

比如:less和scss编译用的包,只有开发时才用得到,实际运行时并不用到,所以就不用放到生产环境依赖包中

-D 或 --save-dev

安装的包将写入packege.json里面的devDependencies,devdependencies:只有开发环境下需要依赖的库

安装本地包

  • 安装本地模块

假如npm_pkg包已经写好(里面只要有个package.json就可以),如

npm install ../npm_pkg
复制代码

通常用来测试本地npm包

  • 将包作为一个命令行工具(cli)
npm install ../npm_demo_cli -g
复制代码

npm install还有很多其他使用方式,不常用,就不一一介绍了。 具体请参照《官方文档》

npm版本号规则

版本号格式

主版本号[MAJOR].次版本号[MINOR].修订号[PATCH]

版本号递增规则如下:

  • 主版本号:当做了不兼容的 API 修改,
  • 次版本号:当做了向下兼容的功能性新增,
  • 修订号:当做了向下兼容的问题修正。先行版本号及版本编译信息可以加到“主版本号.次版本号.修订号”的后面,作为延伸。

当主版本号升级后,次版本号和修订号需要重置为0,次版本号进行升级后,修订版本需要重置为0。

关于测试版本后缀命名:

  • alpha:初期内测版,会有很多bug, 如:1.0.0-alpha.1。
  • beta:中期内测,但会持续加入新的功能。
  • rc:Release Candidate 系统平台上就是发行候选版本。RC版不会再加入新的功能了,主要着重于除错,处在beta版之后,正式版之前

semver:semantic version 语义化版本

  • 固定版本:例如 1.0.1、1.2.1-beta.0 这样表示包的特定版本的字符串
  • 范围版本:是对满足特定规则的版本的一种表示,例如 1.0.3-2.3.4、1.x、^0.2、>1.4

语义化说明

用到的语义化字符有: ~、>、<、=、>=、<=、-、||、x、X、*

'^2.1.1' // 2.x最新版本(主版本号锁定)
'~2.1.1' // 2.1.x最新版本好(主和次版本号锁定)
'>2.1'   // 高于2.1版本的最新版本
'1.0.0 - 1.2.0' // 两个版本之间最新的版本(必须要有空格)
'*'      // 最新的版本号
'3.x'    // 对应x部分最新的版本号
复制代码

npm install默认安装 ^x.x.x类型的版本,用于兼容大版本下最新的版本

npm安装过程

  • 执行工程自身preinstall

  • 确定首层依赖模块

    • 即:package.json中的 dependencies 和 devDependencies
  • 获取模块

    • 在下载一个模块之前,首先要确定其版本,这是因为 package.json 中往往是 semver版本
    • 此时如果版本描述文件(npm-shrinkwrap.json 或 package-lock.json)中有该模块信息直接拿即可

    如果npm-shrinkwrap.json和package-lock.json同时存在,则以npm-shrinkwrap.json为主,忽略另一个

    • 如果没有则从仓库获取(向registry查询)。如 packaeg.json 中某个包的版本是 ^1.1.0,npm 就会去仓库中获取符合 1.x.x 形式的最新版本。
  • 获取模块内容

    • 上一步会获取到模块的压缩包地址(resolved 字段),npm 会用此地址检查本地缓存,缓存中有就直接拿,如果没有则从仓库下载
  • 查找该模块依赖

    • 如果有依赖则回到第1步,如果没有则停止。
  • 模块扁平化

    • 遍历所有节点,逐个将模块放在根节点下面,也就是 node-modules 的第一层。当发现有重复模块时,则将其丢弃

    • 这里需要对重复模块进行一个定义,它指的是模块名相同且 semver 兼容。每个 semver 都对应一段版本允许范围,如果两个模块的版本允许范围存在交集,那么就可以得到一个兼容版本,而不必版本号完全一致,这可以使更多冗余模块在 dedupe 过程中被去掉。

      比如

      node-modules 下 foo 模块依赖 lodash@^1.0.0,bar 模块依赖 lodash@^1.1.0,则 ^1.1.0 为兼容版本。

      而当 foo 依赖 lodash@^2.0.0,bar 依赖 lodash@^1.1.0,则依据 semver 的规则,二者不存在兼容版本。会将一个版本放在 node_modules 中,另一个仍保留在依赖树里。

  • 安装模块

    • 这一步将会更新工程中的 node_modules,并执行模块中的生命周期函数(按照 preinstall、install、postinstall 的顺序)。
  • 执行工程自身生命周期

    • 当前 npm 工程如果定义了钩子此时会被执行
  • 最后一步是生成或更新版本描述文件(package.json和package-lock.json),npm install 过程完成。

安装的npm有子依赖包

如果这个npm还有其他依赖包,会一并安装(只会安装dependencies部分)

devDependencies中的依赖并不会安装

安装的npm包中依赖了同名不同==小版本==的包

A@1
  |-B@1.1
  |-C@1
D@1
  |-B@1.2
E@1
  |-B@1.3
复制代码

这个时候,因为解析的时候,B@1已经在根目录了 那么B@2就会成为D@1中私有模块,即

node_modules
  |-A@1
  |-B@1.3
  |-C@1
  |-D@1
  |-E@1
复制代码

安装的npm包中依赖了同名不同==大版本==的包

A@1
  |-B@1
  |-C@1
D@1
  |-B@2
E@1
  |-B@2
复制代码

这个时候,因为解析的时候,B@1已经在根目录了 那么B@2就会成为D@1中私有模块,即

node_modules
  |-A@1
  |-B@1
  |-C@1
  |-D@1
    |-node_modules
       |-B@2
  |-E@1
    |-node_modules
       |-B@2
复制代码

后面版本的npm包,即使是之前在私有目录中安装过,也同样会重复安装

那同样版本的npm包会多次安装么

package.lock.json

npm 5版本引入了package.lock.json

即在npm install之后会在根目录下生成一个package.lock.json文件

举个例子

{
  ...
  "babel-polyfill": {
    "version": "6.26.0",
    "resolved": "https://rcnpm.zhuanspirit.com/babel-polyfill/download/babel-polyfill-6.26.0.tgz",
    "integrity": "sha1-N5k3q8Z9eJWXCtxiHyhM2WbPIVM=",
    "requires": {
      "babel-runtime": "6.26.0",
      "core-js": "2.6.5",
      "regenerator-runtime": "0.10.5"
    },
    "dependencies": {
      "regenerator-runtime": {
        "version": "0.10.5",
        "resolved": "https://rcnpm.zhuanspirit.com/regenerator-runtime/download/regenerator-runtime-0.10.5.tgz",
        "integrity": "sha1-M2w+/BIgrc7dosn6tntaeVWjNlg="
      }
    }
  }
}
复制代码

结构很简单:

  • babel-polyfill: 包名字
  • version:安装的版本号
  • resolved:npm压缩包下载地址
  • integrity:sha1值(一种哈希算法)按内容计算后的值
  • requires:所依赖的包信息
  • dependencies:requires的模块中所依赖的包,且和根目录中版本不一致的包信息

那它是做什么用的?

锁定安装时包的版本号,并且可以上传到git

保证每个人安装的依赖是一样的

为什么要生成这个文件?

因为npm install -D xxx 之后,默认版本是向后兼容的

比如:

"dependencies": {
    "core-js": "^3.2.0",
}
复制代码

^3.2.0 即表示3.x版本中最新的版本

也就是说package.json中锁定的其实是大版本号,而小版本每次安装都是取最新的。

假如说后面又发布了3.x更高版本,那么后面执行npm install同学安装的就是更高的版本了,比如3.5.0

当然,上面说的版本号规则都是所谓的“规则”,并没有什么强制校验的措施,遵不遵守全凭自觉。所以很有可能出现:

即使是小版本也会出现和之前版本不兼容的情况。

所以,锁定当前的npm包的版本号就很有必要,package.lock.json 也就应运而生了。

那么package.lock.json作用就是:锁定npm包小版本号

问题:那npm install时,如果package.json和package-lock.json都存在,以哪个为主?

其实只有一条规则:==如果package-lock中的版本,在package.json范围内,就以package-lock为主,否则以package.json为主==

比如:以core-js为例子

1)场景一

package.json 中是 "^3.2.0", package-lock.json 中是 "3.1.0"

兼容范围是3.2.0+版本,而3.1.0是在这范围之外(比这小),所以安装时以package.json的^3.2.0为主,就会安装3.x最新的版本(目前是3.5.0)

2)场景二

package.json 中是 "^3.1.0", package-lock.json 中是 "3.2.0"

兼容范围是3.1.0+版本,而3.2.0正符合这个范围,所以安装就按照package-lock.json中指定的3.2.0版本

npm script

生命周期

node为script指令提供了生命周期钩子

  • preXXX - XXX命令之前之前调用
  • postXXx - XXX命令之后调用

举个例子,比如package.json中:

"scripts": {
  "aaa": "echo \"Log: aaa specified\""
}
复制代码

当执行下面脚本时

npm run aaa
复制代码

实际上等价于际执行

if (preaaa) npm run preaaa
npm run aaa
if (postaaa) npm run postaaa
复制代码

所以,进一步实验

"scripts": {
  "aaa": "echo \"Log: aaa specified\"",
  "preaaa": "echo \"Log: preaaa specified\"",
  "postaaa": "echo \"Log: postaaa specified\" & exit 1"
}
复制代码

结果为:

E:\work\npm_test>npm run aaa

> npm_test@1.0.0 preaaa E:\work\npm_test
> echo "Log: preaaa specified"

"Log: preaaa specified"

> npm_test@1.0.0 aaa E:\work\npm_test
> echo "Log: aaa specified"

"Log: aaa specified"

> npm_test@1.0.0 postaaa E:\work\npm_test
> echo "Log: postaaa specified"

"Log: postaaa specified"
复制代码

./node_modules/.bin/

npm run执行时,会把./node_modules/.bin/ 目录添加到执行环境的 PATH 变量中

这样,即便只在当前项目里安装了某个包,npm run一样可以调用

传参

执行 script 脚本如果需要传入参数,需要在命令后加 -- 标明, 如:

npm run dev -- -r main

复制代码

将自定义参数r=main传入dev命令中

process.env

在执行的script 脚本中,可以直接使用process.env对象,它会返回所有和执行环境相关的信息

  • npm_lifecycle_event - 正在运行的脚本名称
  • npm_package_ - 当前项目 package.json 中指定字段的配置值:如 npm_package_name 获取包名
  • npm_package__ - package.json 中嵌套属性:如:npm_package_dependencies_core_js

注:获取属性时,如果是带有中划线的属性,需要改成下划线,如core-js需要改成core_js

npm常见疑问

npm cache clean --force

删除npm_cache下所有缓存文件

删除后,package-lock.json文件中就找不到对应的sha1内容了,就会强制重新从服务器拉取npm包

npm cache verify

重新计算npm_cache下所有缓存文件是否与sha1值匹配,如果不匹配可能删除

npm install发生错误(大招)

删除package.lock.json文件

npm cache clean --force强制删除缓存中的npm包