npm基础回顾

时间  2019-12-16
标签 npm 基础 回顾 繁體版
原文   原文链接

概述

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

npm是什么

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

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

npm配置

环境变量

windows 安装完node一般会自动设置环境变量PATHnode

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

若是不配置呢？git

error：node不是内部或外部命令，也不是可运行的程序 或批处理文件。算法

npm配置项

查看npm配置数据库

npm config ls 或 npm config list
复制代码

image

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

这里面核心的是三项json

  • 当前的用户信息（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缓存的目录windows

$ 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

这两个命令是同样的，一个全写一个简写bash

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.2.1-beta.0 这样表示包的特定版本的字符串
  • 范围版本：是对知足特定规则的版本的一种表示，例如 1.0.3-2.3.四、1.x、^0.二、>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包

相关文章
相关标签/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公众号
   欢迎关注本站公众号,获取更多信息
联系我们 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程