前端项目开发工程化需要哪些npm知识储备？

2019-06-2018:55:13WEB前端开发Comments2,223 views字数 18138阅读模式

npm在前端开发流程中提供了非常完善的自动化工具链，已成为每个前端开发者必备的工具，但是同样由于其强大性导致很多前端开发者只会简单的使用它。本文将总结在日常开发中所需要的npm知识点，以便开发者们更好的利用npm来辅助项目开发。文章源自菜鸟学院-https://www.cainiaoxueyuan.com/gcs/13695.html

1、npm 处理 node_modules 目录结构

node_modules是一个项目开发、上线所依赖的插件包集合。由于node_modules里面的内容繁多，很多开发者并不会在意这个目录里的文件结构细节，只是在开发中按照需求引入这些依赖包即可，但了解node_modules的内容可以帮助我们更好的理解npm是如何处理这些文件的。文章源自菜鸟学院-https://www.cainiaoxueyuan.com/gcs/13695.html

假设项目App中有如下三个依赖：文章源自菜鸟学院-https://www.cainiaoxueyuan.com/gcs/13695.html

"dependencies": {
    A: "1.0.0",
    B: "1.0.0",
    C: "1.0.0"
}
复制代码

A、B、C三个模块又有如下依赖：文章源自菜鸟学院-https://www.cainiaoxueyuan.com/gcs/13695.html

A@1.0.0 -> D@1.0.0

B@1.0.0 -> D@2.0.0

C@1.0.0 -> D@1.0.0
复制代码

npm 2.x - 嵌套结构

npm 2.x安装依赖方式比较简单直接，以递归的方式按照包依赖的树形结构下载填充本地目录结构，也就是说每个包都会将该包的依赖安装到当前包所在的node_modules目录中。文章源自菜鸟学院-https://www.cainiaoxueyuan.com/gcs/13695.html

执行npm install后，项目App的node_modules会变成如下目录结构：文章源自菜鸟学院-https://www.cainiaoxueyuan.com/gcs/13695.html

├── node_modules
│   ├── A@1.0.0
│   │   └── node_modules
│   │   │   └── D@1.0.0
│   ├── B@1.0.0
│   │   └── node_modules
│   │   │   └── D@2.0.0
│   └── C@1.0.0
│   │   └── node_modules
│   │   │   └── D@1.0.0

复制代码

很显然这样的依赖组织结构，有如下优点：文章源自菜鸟学院-https://www.cainiaoxueyuan.com/gcs/13695.html

  • 层级结构明显
  • 简单的实现了多版本兼容
  • 保证了对依赖包无论是安装还是删除都会有统一的行为和结构

但是缺点也一样很明显：文章源自菜鸟学院-https://www.cainiaoxueyuan.com/gcs/13695.html

  • 可能造成相同模块的大量冗余问题
  • 可能造成目录结构嵌套比较深

npm 3.x - 扁平结构

npm 3.x则采用了扁平化的结构来安装组织node_modules。也就是在执行npm install的时候，按照package.json 里依赖的顺序依次解析，遇到新的包就把它放在第一级目录，后面如果遇到一级目录已经存在的包，会先按照约定版本判断版本，如果符合版本约定则忽略，否则会按照npm 2.x的方式依次挂在依赖包目录下。文章源自菜鸟学院-https://www.cainiaoxueyuan.com/gcs/13695.html

还以项目App为例，在npm 3.x环境下，执行npm install后，node_modules会变成如下目录结构：文章源自菜鸟学院-https://www.cainiaoxueyuan.com/gcs/13695.html

├── node_modules
│   ├── A@1.0.0
│   ├── D@1.0.0
│   ├── B@1.0.0
│   │   └── node_modules
│   │   │   └── D@2.0.0
│   └── C@1.0.0
复制代码

模块的安装次序决定了node_modules中的目录结构，npm会优先将模块安装在根目录下的node_modules中。文章源自菜鸟学院-https://www.cainiaoxueyuan.com/gcs/13695.html

再在项目中安装模块E@1.0.0（依赖于模块D@2.0.0），目录结构变为：文章源自菜鸟学院-https://www.cainiaoxueyuan.com/gcs/13695.html

├── node_modules
│   ├── A@1.0.0
│   ├── D@1.0.0
│   ├── B@1.0.0
│   │   └── node_modules
│   │   │   └── D@2.0.0
│   └── C@1.0.0
│   ├── E@1.0.0
│   │   └── node_modules
│   │   │   └── D@2.0.0
复制代码

B、E模块下都包含了依赖的模块D@2.0.0，存在代码冗余的情况。文章源自菜鸟学院-https://www.cainiaoxueyuan.com/gcs/13695.html

再在项目中安装模块F@1.0.0（依赖于模块D@1.0.0）。由于D@1.0.0已经存在于项目根目录下的node_modules 下，所以在安装F模块的时候，无需再在其依赖包中安装D@1.0.0模块，目录结构变为：文章源自菜鸟学院-https://www.cainiaoxueyuan.com/gcs/13695.html

├── node_modules
│   ├── A@1.0.0
│   ├── D@1.0.0
│   ├── B@1.0.0
│   │   └── node_modules
│   │   │   └── D@2.0.0
│   └── C@1.0.0
│   ├── E@1.0.0
│   │   └── node_modules
│   │   │   └── D@2.0.0
│   └── F@1.0.0
复制代码

从以上结构可以看出，npm 3.x并没有完美的解决npm 2.x中的问题，甚至还会退化到npm 2.x的行为。文章源自菜鸟学院-https://www.cainiaoxueyuan.com/gcs/13695.html

为了解决目录中存在很多副本的情况，（在A、C模块的依赖模块D升级到2.0.0前提下）可以通过**npm dedupe**指令把所有二级的依赖模块D@2.0.0重定向到一级目录下：文章源自菜鸟学院-https://www.cainiaoxueyuan.com/gcs/13695.html

├── node_modules
│   ├── A@1.0.0
│   ├── D@2.0.0
│   ├── B@1.0.0
│   └── C@1.0.0
│   ├── E@1.0.0
│   └── F@1.0.0
复制代码

node_modules路径查找机制：模块再找对应的依赖包时，nodejs会尝试从当前模块所在目录开始，尝试在它的node_modules 文件夹里加载相应模块，如果没有找到，那么就再向上一级目录移动，直到全局安装路径中的node_modules为止。文章源自菜鸟学院-https://www.cainiaoxueyuan.com/gcs/13695.html

npm 5.x - package-lock.json

从npm 5.x开始，安装组织node_modules和npm 3.x一样采用了扁平化的方式，最大的变化是增加了 package-lock.json 文件。文章源自菜鸟学院-https://www.cainiaoxueyuan.com/gcs/13695.html

npm为了让开发者在安全的前提下使用最新的依赖包，在package.json中通常做了锁定大版本的操作，这样在每次npm install的时候都会拉取依赖包大版本下的最新的版本。这种机制最大的一个缺点就是当有依赖包有小版本更新时，可能会出现协同开发者的依赖包不一致的问题。文章源自菜鸟学院-https://www.cainiaoxueyuan.com/gcs/13695.html

package-lock.json文件精确描述了node_modules 目录下所有的包的树状依赖结构，每个包的版本号都是完全精确的。以sass-loader在package-lock.json中为例：文章源自菜鸟学院-https://www.cainiaoxueyuan.com/gcs/13695.html

"dependencies": {
  "sass-loader": {
    "version": "7.1.0",
    "resolved": "http://registry.npm.taobao.org/sass-loader/download/sass-loader-7.1.0.tgz",
    "integrity": "sha1-Fv1ROMuLQkv4p1lSihly1yqtBp0=",
    "dev": true,
    "requires": {
      "clone-deep": "^2.0.1",
      "loader-utils": "^1.0.1",
      "lodash.tail": "^4.1.1",
      "neo-async": "^2.5.0",
      "pify": "^3.0.0",
      "semver": "^5.5.0"
    },
    "dependencies": {
      "pify": {
        "version": "3.0.0",
        "resolved": "http://registry.npm.taobao.org/pify/download/pify-3.0.0.tgz",
        "integrity": "sha1-5aSs0sEB/fPZpNB/DbxNtJ3SgXY=",
        "dev": true
      }
    }
  }
}

复制代码

package-lock.json的详细描述主要由version、resolved、integrity、dev、requires、dependencies这几个字段构成：文章源自菜鸟学院-https://www.cainiaoxueyuan.com/gcs/13695.html

  • version：包唯一的版本号
  • resolved：安装源
  • integrity：表明包完整性的hash值（验证包是否已失效）
  • dev：如果为true，则此依赖关系仅是顶级模块的开发依赖关系或者是一个的传递依赖关系
  • requires：依赖包所需要的所有依赖项，对应依赖包package.json里dependencies中的依赖项
  • dependencies：依赖包node_modules中依赖的包，与顶层的dependencies一样的结构

在上面的package-lock.json文件中可以发现，在requires和dependencies中都存在pify依赖项。那我们顺便去node_modules里面探下究竟：文章源自菜鸟学院-https://www.cainiaoxueyuan.com/gcs/13695.html

  1. 打开根目录的node_modules会发现安装了sass-loader所需要的所有依赖包，这些依赖包中除了pify以外，所有依赖包的大版本号都与sass-loader所需要的一致。
  2. 到根目录的node_modules找到pify依赖包，发现版本为4.0.1。
  3. 找到sass-loader项目依赖包，打开其node_modules发现其中也存在个pify依赖包，但版本为3.0.0。这个版本的sass-loader真正依赖的是这个版本的pify。

通过以上几个步骤，也验证了之前阐述过的npm 5.x是扁平化处理依赖的方式。文章源自菜鸟学院-https://www.cainiaoxueyuan.com/gcs/13695.html

在开发一个应用时，建议把package-lock.json文件提交到代码版本仓库，从而让你的团队成员、运维部署人员或CI系统可以在执行npm install时安装的依赖版本都是一致的。而且，由于package-lock.json是文本文件，大家也可以清楚地看到谁更改了里面哪个依赖，从而更好的定位和发现问题。文章源自菜鸟学院-https://www.cainiaoxueyuan.com/gcs/13695.html

但是在开发一个库时，则不应把package-lock.json文件发布到仓库中。实际上，npm也默认不会把package-lock.json文件发布出去。之所以这么做，是因为库项目一般是被其他项目依赖的，在不写死的情况下，就可以复用主项目已经加载过的包，而一旦库依赖的是精确的版本号那么可能会造成包的冗余。文章源自菜鸟学院-https://www.cainiaoxueyuan.com/gcs/13695.html

2、npm中的依赖包

依赖包分类

在 node 中其实总共有5种依赖：文章源自菜鸟学院-https://www.cainiaoxueyuan.com/gcs/13695.html

  • dependencies - 业务依赖
  • devDependencies - 开发依赖
  • peerDependencies - 同伴依赖
  • bundledDependencies / bundleDependencies - 打包依赖
  • optionalDependencies - 可选依赖

作为npm的使用者，我们常用的依赖是dependencies和devDependencies，剩下三种依赖都是作为包的发布者才会使用到的字段。文章源自菜鸟学院-https://www.cainiaoxueyuan.com/gcs/13695.html

dependencies

这个依赖项在项目最终上线运行所需要，即这些依赖属于线上代码的一部分。比如框架vue，第三方的组件库element-ui等，这些依赖包都是必须装在这个选项里供生产环境使用。文章源自菜鸟学院-https://www.cainiaoxueyuan.com/gcs/13695.html

通过命令npm install/i packageName -S/--save把包装在此依赖项里。如果没有指定版本，直接写一个包的名字，则安装当前npm仓库中这个包的最新版本。如果要指定版本的，可以把版本号写在包名后面，比如npm i vue@3.0.1 -S。文章源自菜鸟学院-https://www.cainiaoxueyuan.com/gcs/13695.html

从npm 5.x开始，可以不用手动添加-S/--save指令，直接执行npm i packageName把依赖包添加到dependencies中去。文章源自菜鸟学院-https://www.cainiaoxueyuan.com/gcs/13695.html

devDependencies

这个依赖项只在项目开发时所需要，即这些依赖不属于线上代码的一部分。比如构建工具webpack、gulp，预处理器babel-loader、scss-loader，测试工具e2e、chai等，这些都是辅助开发的工具包，无须在生产环境使用。文章源自菜鸟学院-https://www.cainiaoxueyuan.com/gcs/13695.html

通过命令npm install/i -D/--save-dev把包安装成开发依赖。如果想缩减安装包，可以使用命令npm i --production忽略开发依赖，只安装基本依赖，这通常在线上机器（或者QA环境）上使用。文章源自菜鸟学院-https://www.cainiaoxueyuan.com/gcs/13695.html

由于dependencies依赖的包不仅开发环境能使用，生产环境也能使用，所以在安装开发依赖的时候，注意不要装在dependencies下，以免造成项目线上体积无谓的增大。文章源自菜鸟学院-https://www.cainiaoxueyuan.com/gcs/13695.html

peerDependencies

这个依赖项的作用是提示宿主环境去安装插件在peerDependencies中所指定依赖的包，然后插件所依赖的包永远都是宿主环境统一安装的npm包，最终解决插件与所依赖包不一致的问题。文章源自菜鸟学院-https://www.cainiaoxueyuan.com/gcs/13695.html

这句话听起来可能有点拗口，举个例子来给大家说明下。element-ui@2.6.3只是提供一套基于vue的ui组件库，但它要求宿主环境需要安装指定的vue版本，所以你可以看到element项目中的package.json中具有一项配置：文章源自菜鸟学院-https://www.cainiaoxueyuan.com/gcs/13695.html

"peerDependencies": {
    "vue": "^2.5.16"
}
复制代码

它要求宿主环境安装3.0.0 > vue@ >= 2.5.16的版本，也就是element-ui的运行依赖宿主环境提供的该版本范围的vue依赖包。文章源自菜鸟学院-https://www.cainiaoxueyuan.com/gcs/13695.html

在安装插件的时候，peerDependencies在npm 2.x和npm 3.x中表现不一样：文章源自菜鸟学院-https://www.cainiaoxueyuan.com/gcs/13695.html

在npm 2.x中，安装包中peerDependencies所指定的依赖会随着npm install packageName一起被强制安装，并且peerDependencies中指定的依赖会安装在宿主环境中，所以不需要在宿主环境的package.json文件中指定对所安装包中peerDependencies内容的依赖。文章源自菜鸟学院-https://www.cainiaoxueyuan.com/gcs/13695.html

在npm 3.x中，不会再要求peerDependencies所指定的依赖包被强制安装，npm 3.x只会在安装结束后检查本次安装是否正确，如果不正确会给用户打印警告提示，比如提示用户有的包必须安装或者有的包版本不对等。文章源自菜鸟学院-https://www.cainiaoxueyuan.com/gcs/13695.html

大白话：如果你安装我，那么你最好也要按照我的要求安装A、B和C。文章源自菜鸟学院-https://www.cainiaoxueyuan.com/gcs/13695.html

bundledDependencies / bundleDependencies

这个依赖项跟npm pack打包命令有关。假设package.json中有如下配置：文章源自菜鸟学院-https://www.cainiaoxueyuan.com/gcs/13695.html

{
  "name": "font-end",
  "version": "1.0.0",
  "dependencies": {
    "fe1": "^0.3.2",
    ...
  },
  "devDependencies": {
    ...
    "fe2": "^1.0.0"
  },
  "bundledDependencies": [
    "fe1",
    "fe2"
  ]
}
复制代码

执行打包命令npm pack，会生成front-end-1.0.0.tgz压缩包，并且该压缩包中包含fe1和fe2两个安装包，这样使用者执行npm install front-end-1.0.0.tgz也会安装这两个依赖。文章源自菜鸟学院-https://www.cainiaoxueyuan.com/gcs/13695.html

在bundledDependencies中指定的依赖包，必须先在dependencies和devDependencies声明过，否则打包会报错。文章源自菜鸟学院-https://www.cainiaoxueyuan.com/gcs/13695.html

optionalDependencies

这个依赖项中的依赖即使安装失败了，也不影响整个安装的过程。需要注意的是，如果一个依赖同时出现在dependencies和optionalDependencies中，那么optionalDependencies会获得更高的优先级，可能造成一些预期之外的效果，所以尽量要避免这种情况发生。文章源自菜鸟学院-https://www.cainiaoxueyuan.com/gcs/13695.html

在实际项目中，如果某个包已经失效，我们通常会寻找它的替代者，或者换一个实现方案。不确定的依赖会增加代码判断和测试难度，所以这个依赖项能不使用还是不要使用了，如果原先就不知道这个，那就继续当做不知道吧。文章源自菜鸟学院-https://www.cainiaoxueyuan.com/gcs/13695.html

依赖包版本号

npm采用了语义化版本(semver)规范作为依赖版本管理方案。文章源自菜鸟学院-https://www.cainiaoxueyuan.com/gcs/13695.html

按照semver的约定，一个npm依赖包的版本格式一般为：主版本号.次版本号.修订号（x.y.z），每个号的含义是：文章源自菜鸟学院-https://www.cainiaoxueyuan.com/gcs/13695.html

  • 主版本号（也叫大版本，major version）大版本的改动很可能是一次颠覆性的改动，也就意味着可能存在与低版本不兼容的API或者用法，（比如 vue 2 -> 3)。
  • 次版本号（也叫小版本，minor version）小版本的改动应当兼容同一个大版本内的API和用法，因此应该让开发者无感。所以我们通常只说大版本号，很少会精确到小版本号。

    特殊情况是如果大版本号是 0 的话，意味着整个包处于内测状态，所以每个小版本之间也可能会不兼容。所以在选择依赖时，尽量避开大版本号是 0 的包。

  • 修订号（也叫补丁，patch）一般用于修复 bug 或者很细微的变更，也需要保持向前兼容。

常见的几个版本格式如下：文章源自菜鸟学院-https://www.cainiaoxueyuan.com/gcs/13695.html

  • "1.2.3"表示精确版本号。任何其他版本号都不匹配。在一些比较重要的线上项目中，建议使用这种方式锁定版本。
  • "^1.2.3"表示兼容补丁和小版本更新的版本号。官方的定义是“能够兼容除了最左侧的非 0 版本号之外的其他变化”(Allows changes that do not modify the left-most non-zero digit in the [major, minor, patch] tuple)。这句话很拗口，举几个例子大家就明白了：
    "^1.2.3" 等价于 ">= 1.2.3 < 2.0.0"。即只要最左侧的 "1" 不变，其他都可以改变。所以 "1.2.4", "1.3.0" 都可以兼容。

"^0.2.3" 等价于 ">= 0.2.3 < 0.3.0"。因为最左侧的是 "0"，那么只要第二位 "2" 不变，其他的都兼容，比如 "0.2.4" 和 "0.2.99"。

"^0.0.3" 等价于 ">= 0.0.3 < 0.0.4"。这里最左侧的非 "0" 只有 "3"，且没有其他版本号了，所以这个也等价于精确的 "0.0.3"。
复制代码

    从这几个例子可以看出，^ 是一个更新和安全兼容的写法。一般大版本号升级到 1 就表示项目正式发布了，而 0 开头就表示还在测试版，这也是 ^ 区别对待两者的原因。

  • "~1.2.3"表示只兼容补丁更新的版本号。关于 ~ 的定义分为两部分：如果列出了小版本号（第二位），则只兼容补丁（第三位）的修改；如果没有列出小版本号，则兼容第二和第三位的修改。我们分两种情况理解一下这个定义：
    "~1.2.3" 列出了小版本号 "2"，因此只兼容第三位的修改，等价于 ">= 1.2.3 < 1.3.0"。

"~1.2" 也列出了小版本号，因此和上面一样兼容第三位的修改，等价于 ">= 1.2.0 < 1.3.0"。

"~1" 没有列出小版本号，可以兼容第二第三位的修改，因此等价于 ">= 1.0.0 < 2.0.0"
复制代码

    和 ^ 不同的是，~ 并不对 0 或者 1 区别对待，所以 "~0" 等价于 ">= 0.0.0 < 1.0.0"，和 "~1" 是相同的算法。比较而言，~ 更加谨慎。当首位是 0 并且列出了第二位的时候，两者是等价的，例如 "~0.2.3" 和 "^0.2.3"。

  • "1.x" 、"1.X"、1.*"、"1"、"*"表示使用通配符的版本号。x、X、* 和 （空） 的含义相同，都表示可以匹配任何内容。具体来说：
    "*" 、"x" 或者 （空） 表示可以匹配任何版本。

"1.x", "1.*" 和 "1" 表示匹配主版本号为 "1" 的所有版本，因此等价于 ">= 1.0.0 < 2.0.0"。

"1.2.x", "1.2.*" 和 "1.2" 表示匹配版本号为 "1.2" 开头的所有版本，因此等价于 ">= 1.2.0 < 1.3.0"。
复制代码
  • "1.2.3-beta.1"带预发布关键词的版本号。先说说几个预发布关键词的定义：
    alpha(α)：预览版，或者叫内部测试版；一般不向外部发布，会有很多bug；一般只有测试人员使用。

beta(β)：测试版，或者叫公开测试版；这个阶段的版本会一直加入新的功能；在alpha版之后推出。

rc(release candidate)：最终测试版本；可能成为最终产品的候选版本，如果未出现问题则可发布成为正式版本。
复制代码

    以包开发者的角度来考虑这个问题：假设当前线上版本是 "1.2.3"，如果我作了一些改动需要发布版本 "1.2.4"，但我不想直接上线（因为使用 "~1.2.3" 或者 "^1.2.3" 的用户都会直接静默更新），这就需要使用预发布功能。因此我可能会发布 "1.2.4-alpha.1" 或者 "1.2.4-beta.1" 等等。文章源自菜鸟学院-https://www.cainiaoxueyuan.com/gcs/13695.html

    ">1.2.4-alpha.1"表示我接受 "1.2.4" 版本所有大于 1 的 alpha 预发布版本。因此如 "1.2.4-alpha.7" 是符合要求的，但 "1.2.4-beta.1" 和 "1.2.5-alpha.2" 都不符合。此外如果是正式版本（不带预发布关键词），只要版本号符合要求即可，不检查预发布版本号，例如 "1.2.5", "1.3.0" 都是认可的。

"~1.2.4-alpha.1" 表示 ">=1.2.4-alpha.1 < 1.3.0"。这样 "1.2.5", "1.2.4-alpha.2" 都符合条件，而 "1.2.5-alpha.1", "1.3.0" 不符合。

"^1.2.4-alpha.1" 表示 ">=1.2.4-alpha.1 < 2.0.0"。这样 "1.2.5", "1.2.4-alpha.2", "1.3.0" 都符合条件，而 "1.2.5-alpha.1", "2.0.0" 不符合。
复制代码

版本号还有更多的写法，例如范围（a - b），大于等于号（>=），小于等于号（<=），或（||）等等，因为用的不多，这里不再展开。详细的文档可以参见 semver，它同时也是一个 npm 包，可以用来比较两个版本号的大小，以及是否符合要求等。文章源自菜鸟学院-https://www.cainiaoxueyuan.com/gcs/13695.html

依赖包版本管理

npm 2.x/3.x已成为过去式，在npm 5.x以上环境下（版本最好在5.6以上，因为在5.0 ~ 5.6中间对package-lock.json的处理逻辑更新过几个版本，5.6以上才开始稳定），管理依赖包版本你应该知道（以^版本为例，其他类型版本参照即可）：文章源自菜鸟学院-https://www.cainiaoxueyuan.com/gcs/13695.html

  1. 在大版本相同的前提下，如果一个模块在package.json中的小版本要大于package-lock.json中的小版本，则在执行npm install时，会将该模块更新到大版本下的最新的版本，并将版本号更新至package-lock.json。如果小于，则被package-lock.json中的版本锁定。
// package-lock.json 中原版本
"clipboard": {
  "version": "1.5.10", 
},
"vue": {
  "version": "2.6.10",
}
// package.json 中修改版本
"dependencies": {
  "clipboard": "^1.5.12",
  "vue": "^2.5.6"
  ...
}

// 执行完 npm install 后，package-lock.json 中
"clipboard": {
  "version": "1.7.1", // 更新到大版本下的最新版本
},
"vue": {
  "version": "2.6.10", // 版本没发生改变
}
复制代码
  1. 如果一个模块在package.json和package-lock.json中的大版本不相同，则在执行npm install时，都将根据package.json中大版本下的最新版本进行更新，并将版本号更新至package-lock.json。
// package-lock.json 中原版
"clipboard": {
  "version": "2.0.4",
}
// package.json 中修改版本
"dependencies": {
  "clipboard": "^1.6.1",
}

// 执行完npm install后，package-lock.json 中
// 
"clipboard": {
  "version": "1.7.1", // 更新到大版本下的最新版本
}
复制代码
  1. 如果一个模块在package.json中有记录，而在package-lock.json中无记录，执行npm install后，则会在package-lock.json生成该模块的详细记录。同理，一个模块在package.json中无记录，而在package-lock.json中有记录，执行npm install后，则会在package-lock.json删除该模块的详细记录。
  2. 如果要更新某个模块大版本下的最新版本（升级小版本号），可以执行以下命令：
npm install packageName
// 或者
npm update packageName
复制代码
  1. 如果要更新到指定版本号（升级大版本号），可以执行如下命令：
npm install packageName@x.x.x
复制代码
  1. 卸载某个模块，可以执行如下命令：
npm unistall packageName
复制代码

通过上述的命令来管理依赖包，package.json和package-lock.json中的版本号都将会随之更新。文章源自菜鸟学院-https://www.cainiaoxueyuan.com/gcs/13695.html

我们在升级/卸载依赖包的时候，尽量通过命令来实现，避免手动修改package.json中的版本号，尤其是不要手动修改package-lock.json。文章源自菜鸟学院-https://www.cainiaoxueyuan.com/gcs/13695.html

3、npm scripts 脚本

package.json中的 scripts 字段可以用来自定义脚本命令，它的每一个属性，对应一段脚本。以vue-cli3为例：文章源自菜鸟学院-https://www.cainiaoxueyuan.com/gcs/13695.html

"scripts": {
  "serve": "vue-cli-service serve",
  ...
}
复制代码

这样就可以通过npm run serve脚本代替vue-cli-service serve脚本来启动项目，而无需每次敲一遍这么冗长的脚本。文章源自菜鸟学院-https://www.cainiaoxueyuan.com/gcs/13695.html

工作原理

package.json 中的 bin 字段

package.json中的字段 bin 表示的是一个可执行文件到指定文件源的映射。例如在@vue/cli-service的package.json中：文章源自菜鸟学院-https://www.cainiaoxueyuan.com/gcs/13695.html

"bin": {
  "vue-cli-service": "bin/vue-cli-service.js"
}
复制代码

如果全局安装@vue/cli-service的话，@vue/cli-service源文件会被安装在全局源文件安装目录（/user/local/lib/node_modules）下，而npm会在全局可执行bin文件安装（/usr/local/bin）目录下创建一个指向../lib/node_modules/@vue/cli-service/bin/vue-cli-service.js文件的名为vue-cli-service的软链接，这样就可以直接在终端输入vue-cli-service来执行。文章源自菜鸟学院-https://www.cainiaoxueyuan.com/gcs/13695.html

如果局部安装@vue/cli-service的话，npm则会在本地项目node_modules/.bin目录下创建一个指向../@vue/cli-service/bin/vue-cli-service.js名为vue-cli-service的软链接，这个时候需要在终端中输入./node_modules/.bin/vue-cli-service来执行（也可以使用npx vue-cli-service命令来执行，npx 的作用就是为了方便调用项目内部安装的模块）。文章源自菜鸟学院-https://www.cainiaoxueyuan.com/gcs/13695.html

软链接（符号链接）是一类特殊的可执行文件， 其包含有一条以绝对路径或者相对路径的形式指向其它文件或者目录的引用。在bin目录下执行ll指令可以查看具体的软链接指向。文章源自菜鸟学院-https://www.cainiaoxueyuan.com/gcs/13695.html

PATH 环境变量

在terminal中执行命令时，命令会在PATH环境变量里包含的路径中去寻找相同名字的可执行文件。局部安装的包只在./node_modules/.bin中注册了它们的可执行文件，不会被包含在PATH环境变量中，这个时候在terminal中输入命令将会报无法找到的错误。文章源自菜鸟学院-https://www.cainiaoxueyuan.com/gcs/13695.html

那为什么通过npm run可以执行局部安装的命令行包呢？文章源自菜鸟学院-https://www.cainiaoxueyuan.com/gcs/13695.html

是因为每当执行npm run时，会自动新建一个Shell，这个 Shell会将当前项目的node_modules/.bin的绝对路径加入到环境变量PATH中，执行结束后，再将环境变量PATH恢复原样。文章源自菜鸟学院-https://www.cainiaoxueyuan.com/gcs/13695.html

我们来验证下这个说法。首先执行 env 查看当前所有的环境变量，可以看到PATH环境变量为：文章源自菜鸟学院-https://www.cainiaoxueyuan.com/gcs/13695.html

PATH=/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin
复制代码

再在当前项目下执行npm run env查看脚本运行时的环境变量，可以看到PATH环境变量为：文章源自菜鸟学院-https://www.cainiaoxueyuan.com/gcs/13695.html

PATH=/usr/local/lib/node_modules/npm/node_modules/npm-lifecycle/node-gyp-bin:/Users/mac/Vue-projects/hao-cli/node_modules/.bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin
复制代码

可以看到运行时的PATH环境变量多了两个路径：npm指令路径和项目中node_modules/.bin的绝对路径。文章源自菜鸟学院-https://www.cainiaoxueyuan.com/gcs/13695.html

所以，通过npm run可以在不添加路径前缀的情况下直接访问当前项目node_modules/.bin目录里面的可执行文件。文章源自菜鸟学院-https://www.cainiaoxueyuan.com/gcs/13695.html

PATH环境变量，是告诉系统，当要求系统运行一个程序而没有告诉它程序所在的完整路径时，系统除了在当前目录下面寻找此程序外，还应到哪些目录下去寻找。文章源自菜鸟学院-https://www.cainiaoxueyuan.com/gcs/13695.html

用法指南

传入参数

关于scripts中的参数，这里要多说几句。网上有很多不是很准确的说法，经过本人的反复试验，node处理scripts参数其实很简单，比如：文章源自菜鸟学院-https://www.cainiaoxueyuan.com/gcs/13695.html

"scripts": {
  "serve": "vue-cli-service serve",
  "serve1": "vue-cli-service --serve1",
  "serve2": "vue-cli-service -serve2",
  "serve3": "vue-cli-service serve --mode=dev --mobile -config build/example.js"
}
复制代码

除了第一个可执行的命令，以空格分割的任何字符串（除了一些shell的语法）都是参数，并且都能通过process.argv属性访问。文章源自菜鸟学院-https://www.cainiaoxueyuan.com/gcs/13695.html

process.argv属性返回一个数组，这个数组包含了启动node进程时的命令行参数。第一个元素为启动node 进程的可执行文件的绝对路径名process.execPath，第二个元素为当前执行的JavaScript文件路径。剩余的元素为其他命令行参数。文章源自菜鸟学院-https://www.cainiaoxueyuan.com/gcs/13695.html

比如执行npm run serve3命令，process.argv的具体内容为：文章源自菜鸟学院-https://www.cainiaoxueyuan.com/gcs/13695.html

[ '/usr/local/Cellar/node/7.7.1_1/bin/node',
  '/Users/mac/Vue-projects/hao-cli/node_modules/.bin/vue-cli-service',
  'serve',
  '--mode=dev',
  '--mobile',
  '-config',
  'build/example.js']
复制代码

很多命令行包之所以这么写，都是依赖了 minimist 或者 yargs 等参数解析工具来对命令行参数进行解析。文章源自菜鸟学院-https://www.cainiaoxueyuan.com/gcs/13695.html

以minimist对vue-cli-service serve --mode=dev --mobile -config build/example.js解析为例，解析后的结果为：文章源自菜鸟学院-https://www.cainiaoxueyuan.com/gcs/13695.html

{ _: [ 'serve' ],
  mode: 'dev',
  mobile: true,
  config: 'build/example.js',
  '$0': '/Users/mac/Vue-projects/hao-cli/node_modules/.bin/vue-cli-service'}
复制代码

在./node_modules/.bin/vue-cli-service文件中可以看到minimist对命令行参数的处理：文章源自菜鸟学院-https://www.cainiaoxueyuan.com/gcs/13695.html

const rawArgv = process.argv.slice(2)
const args = require('minimist')(rawArgv, {
  boolean: [
    // build
    'modern',
    'report',
    'report-json',
    'watch',
    // serve
    'open',
    'copy',
    'https',
    // inspect
    'verbose'
  ]
})
const command = args._[0]
service.run(command, args, rawArgv).catch(err => {
  error(err)
  process.exit(1)
})
复制代码

我们还可以通过命令行传参的形式来进行参数传递：文章源自菜鸟学院-https://www.cainiaoxueyuan.com/gcs/13695.html

npm run serve --params  // 参数params将转化成process.env.npm_config_params = true
npm run serve --params=123 // 参数params将转化成process.env.npm_config_params = 123
npm run serve -params  // 等同于--params参数

npm run serve -- --params  // 将--params参数添加到process.env.argv数组中
npm run serve params  // 将params参数添加到process.env.argv数组中
npm run serve -- params  // 将params参数添加到process.env.argv数组中
复制代码

多命令运行

有的项目在启动时可能需要同时执行多个任务，多个任务的执行顺序决定了项目的表现。文章源自菜鸟学院-https://www.cainiaoxueyuan.com/gcs/13695.html

串行执行

串行执行，要求前一个任务执行成功以后才能执行下一个任务，使用&&符号来连接。文章源自菜鸟学院-https://www.cainiaoxueyuan.com/gcs/13695.html

npm run script1 && npm run script2
复制代码

串行命令执行过程中，只要一个命令执行失败，则整个脚本终止。文章源自菜鸟学院-https://www.cainiaoxueyuan.com/gcs/13695.html

并行执行

并行执行，就是多个命令可以同时的平行执行，使用&符号来连接。文章源自菜鸟学院-https://www.cainiaoxueyuan.com/gcs/13695.html

npm run script1 & npm run script2
复制代码

这两个符号是Bash的内置功能。此外，还可以使用第三方的任务管理器模块：script-runner、npm-run-all、redrun。文章源自菜鸟学院-https://www.cainiaoxueyuan.com/gcs/13695.html

env 环境变量

在执行npm run脚本时，npm会设置一些特殊的env环境变量。其中package.json中的所有字段，都会被设置为以npm_package_ 开头的环境变量。比如package.json中有如下字段内容：文章源自菜鸟学院-https://www.cainiaoxueyuan.com/gcs/13695.html

{
  "name": "sh",
  "version": "1.1.1",
  "description": "shenhao",
  "main": "index.js",
  "repository": {
    "type": "git",
    "url": "git+ssh://git@gitlab.com/xxxx/sh.git"
  }
}
复制代码

可以通过process.env.npm_package_name 可以获取到package.json中name字段的值sh，也可以通过process.env.npm_package_repository_type获取到嵌套属性type的值git。文章源自菜鸟学院-https://www.cainiaoxueyuan.com/gcs/13695.html

同时，npm相关的所有配置也会被设置为以npm_config_开头的环境变量。文章源自菜鸟学院-https://www.cainiaoxueyuan.com/gcs/13695.html

此外，还会设置一个比较特殊的环境变量npm_lifecycle_event，表示正在运行的脚本名称。比如执行npm run serve 的时候，process.env.npm_lifecycle_event值为serve，通过判断这个变量，可以将一个脚本使用在不同的npm scripts中。文章源自菜鸟学院-https://www.cainiaoxueyuan.com/gcs/13695.html

这些环境变量只能在npm run的脚本执行环境内拿到，正常执行的node脚本是获取不到的。所以，不能直接通过env $NODE_ENV的形式访问，但可以在scripts中定义脚本"scripts": "echo $NODE_ENV"来访问。文章源自菜鸟学院-https://www.cainiaoxueyuan.com/gcs/13695.html

指令钩子

在执行npm scripts命令（无论是自定义还是内置）时，都经历了pre和post两个钩子，在这两个钩子中可以定义某个命令执行前后的命令。文章源自菜鸟学院-https://www.cainiaoxueyuan.com/gcs/13695.html

比如在执行npm run serve命令时，会依次执行npm run preserve、npm run serve、npm run postserve，所以可以在这两个钩子中自定义一些动作：文章源自菜鸟学院-https://www.cainiaoxueyuan.com/gcs/13695.html

"scripts": {
  "preserve": "xxxxx",
  "serve": "vue-cli-service serve",
  "postserve": "xxxxxx"
}
复制代码

当然，如果没有指定preserve、postserve，会默默的跳过。如果想要指定钩子，必须严格按照pre和post前缀来添加。文章源自菜鸟学院-https://www.cainiaoxueyuan.com/gcs/13695.html

上面提到过一个环境变量process.env.npm_lifecycle_event可以配合钩子来一起使用：文章源自菜鸟学院-https://www.cainiaoxueyuan.com/gcs/13695.html

const event = process.env.npm_lifecycle_event

if (event === 'preserve') {
    console.log('Running the preserve task!')
} else if (_event === 'serve') {
    console.log('Running the serve task!')
}
复制代码

4、npm 配置

npm的配置操作可以帮助我们预先设定好npm对项目的行为动作，也可以让我们预先定义好一些配置项以供项目中使用。所以了解npm的配置机制也是很有必要。文章源自菜鸟学院-https://www.cainiaoxueyuan.com/gcs/13695.html

优先级

npm可以从不同的来源获取其配置值，按优先级从高到低的顺序排序：文章源自菜鸟学院-https://www.cainiaoxueyuan.com/gcs/13695.html

命令行

npm run serve --params=123
复制代码

执行上述命令时，会将配置项params的值设为123，通过process.env.npm_config_params可以访问其配置值。这个时候的params配置值将覆盖所有其他来源存在的params配置值。文章源自菜鸟学院-https://www.cainiaoxueyuan.com/gcs/13695.html

env 环境变量

如果env环境变量中存在以npm_config_为前缀的环境变量，则会被识别为npm的配置属性。比如在env环境变量中设置npm_config_package_lock变量：文章源自菜鸟学院-https://www.cainiaoxueyuan.com/gcs/13695.html

export npm_config_package_lock=false // 修改的是内存中的变量，只对当前终端有效
复制代码

这时候执行npm install，npm会从环境变量中读取到这个配置项，从而不会生成package-lock.json文件。文章源自菜鸟学院-https://www.cainiaoxueyuan.com/gcs/13695.html

查看某个环境变量：echo $NODE_ENV
删除某个环境变量：unset NODE_ENV文章源自菜鸟学院-https://www.cainiaoxueyuan.com/gcs/13695.html

npmrc 文件

通过修改 npmrc 文件可以直接修改配置。系统中存在多个npmrc文件，这些npmrc文件被访问的优先级从高到低的顺序为：文章源自菜鸟学院-https://www.cainiaoxueyuan.com/gcs/13695.html

  • 项目级的.npmrc文件只作用在本项目下。在其他项目中，这些配置不生效。通过创建这个.npmrc文件可以统一团队的npm配置规范。
  • 用户级的.npmrc文件mac下的地址为~/.npmrc。（npm config get userconfig可以看到存放的路径）
  • 全局级的npmrc文件mac下的地址为$PREFIX/etc/npmrc。（npm config get globalconfig可以看到存放的路径）
  • npm内置的npmrc文件这是一个不可更改的内置配置文件，为了维护者以标准和一致的方式覆盖默认配置。mac下的地址为/path/to/npm/npmrc。

.npmrc参照 npm/ini 格式编写。文章源自菜鸟学院-https://www.cainiaoxueyuan.com/gcs/13695.html

默认配置

通过npm config ls -l查看npm内部的默认配置参数。如果命令行、环境变量、所有配置文件都没有配置参数，则使用默认参数值。文章源自菜鸟学院-https://www.cainiaoxueyuan.com/gcs/13695.html

npm config 指令

npm提供了几个 npm config 指令来进行用户级和全局级配置：文章源自菜鸟学院-https://www.cainiaoxueyuan.com/gcs/13695.html

set

npm config set <key> <value> [-g|--global]
npm config set registry <url> // 指定下载 npm 包的来源，默认为 https://registry.npmjs.org/ ，可以指定私有源
复制代码

使用-g|--global标志修改或新增全局级配置，不使用的话修改或者新增用户级配置（相应级别的.npmrc文件会更新）。文章源自菜鸟学院-https://www.cainiaoxueyuan.com/gcs/13695.html

如果key不存在，则会新增到配置中。如果省略value，则key会被设置成true。文章源自菜鸟学院-https://www.cainiaoxueyuan.com/gcs/13695.html

还可以覆盖package.json中config字段的值：文章源自菜鸟学院-https://www.cainiaoxueyuan.com/gcs/13695.html

// package.json
{
  "name" : "foo",
  "config" : { "port" : "8080" },
  "scripts" : { "start" : "node server.js" }
}
复制代码
// server.js
console.log(process.env.npm_package_config_port)
复制代码
npm config set foo:port 8000 // 打印8000
复制代码

get

npm config get <key>
npm config get prefix // 获取npm的安装路径
复制代码

按照配置优先级，获取指定配置项的值。文章源自菜鸟学院-https://www.cainiaoxueyuan.com/gcs/13695.html

delete

npm config delete <key>
复制代码

npm官网上说可以删除所有配置文件中指定的配置项，但经实验无法删除项目级的.npmrc文件里指定的配置项。文章源自菜鸟学院-https://www.cainiaoxueyuan.com/gcs/13695.html

list

npm config list [-l] [--json]
复制代码

加上-l或者--json查看所有的配置项，包括默认的配置项。不加的话，不能查看默认的配置项。文章源自菜鸟学院-https://www.cainiaoxueyuan.com/gcs/13695.html

edit

npm config edit [-g|--global]
复制代码

在编辑器中打开配置文件。使用-g|--global标志编辑全局级配置和默认配置，不使用的话编辑用户级配置和默认配置。文章源自菜鸟学院-https://www.cainiaoxueyuan.com/gcs/13695.html

参考 npm config 来获取npm提供的默认配置。文章源自菜鸟学院-https://www.cainiaoxueyuan.com/gcs/13695.html

5、npm 的几个实用技巧

自定义默认的 npm init

使用npm init初始化一个新的项目时会提示你去填写一些项目描述信息。如果觉得填写这些信息比较麻烦的话，可以使用-y标记表示接受package.json中的一些默认值：文章源自菜鸟学院-https://www.cainiaoxueyuan.com/gcs/13695.html

npm init -y
复制代码

也可以设置初始化的默认值：文章源自菜鸟学院-https://www.cainiaoxueyuan.com/gcs/13695.html

npm config set init-author-name <name> // 为 npm init 设置了默认的作者名
复制代码

查看 npm 脚本命令

查看当前项目的所有npm脚本命令最直接的办法就是打开项目中的package.json文件并检查scripts字段。我们还可以使用不带任何参数的npm run命令查看：文章源自菜鸟学院-https://www.cainiaoxueyuan.com/gcs/13695.html

npm run
复制代码

查看环境变量

通过env查看当前的所有环境变量，而查看运行时的所有环境变量可以执行：文章源自菜鸟学院-https://www.cainiaoxueyuan.com/gcs/13695.html

npn run env
复制代码

模块管理

查看当前项目依赖的所有模块，包括子模块以及子模块的子模块：文章源自菜鸟学院-https://www.cainiaoxueyuan.com/gcs/13695.html

npm list/ls
复制代码

如果还想查看模块的一些描述信息（package.json中的description中的内容）：文章源自菜鸟学院-https://www.cainiaoxueyuan.com/gcs/13695.html

npm la/ll // 相当于npm ls --long
复制代码

一个项目依赖的模块往往很多，可以限制输出模块的层级来查看：文章源自菜鸟学院-https://www.cainiaoxueyuan.com/gcs/13695.html

npm list/ls --depth=0 // 只列出父包依赖的模块
复制代码

查看一个模块到底是因为谁被安装进来的，如果显示为空则表明该模块为内置模块或者不存在：文章源自菜鸟学院-https://www.cainiaoxueyuan.com/gcs/13695.html

npm ll <packageName>
复制代码

查看当前项目中可升级的模块的信息来更新模块：文章源自菜鸟学院-https://www.cainiaoxueyuan.com/gcs/13695.html

npm outdated
复制代码

整理项目中无关的模块：文章源自菜鸟学院-https://www.cainiaoxueyuan.com/gcs/13695.html

npm prune
复制代码

查看项目中某个模块的当前版本信息：文章源自菜鸟学院-https://www.cainiaoxueyuan.com/gcs/13695.html

npm list/ls <packageName>
复制代码

查看某个模块最新的和历史的版本信息：文章源自菜鸟学院-https://www.cainiaoxueyuan.com/gcs/13695.html

npm view/info <packageName> version // 模块最新的版本信息（不包括预发布版本）
npm view/info <packageName> versions // 模块所有的历史版本信息（包括预发布版本）
复制代码

查看独立模块的所有信息，包括它的依赖、关键字、更新日期、贡献者、仓库地址和许可证等：文章源自菜鸟学院-https://www.cainiaoxueyuan.com/gcs/13695.html

npm view/info <packageName>
复制代码

查看模块文档

打开模块的 github 主页：文章源自菜鸟学院-https://www.cainiaoxueyuan.com/gcs/13695.html

npm repo <packageName> 
复制代码

打开模块的文档地址：文章源自菜鸟学院-https://www.cainiaoxueyuan.com/gcs/13695.html

npm docs <packageName>
复制代码

打开模块的 issues 地址：文章源自菜鸟学院-https://www.cainiaoxueyuan.com/gcs/13695.html

npm bugs <packageName>
复制代码

版本管理

在package.json中有个version字段代表的是该模块的版本信息。当发布新版本时，version字段也要进行相应的改变。虽然可以手动的修改vsersion字段，但是为了整个发布的过程的自动化，最好还是使用指令的形式来进行修改：文章源自菜鸟学院-https://www.cainiaoxueyuan.com/gcs/13695.html

npm version major // 大版本号加1
npm version minor // 小版本号字加1
npm version patch // 补丁号加1
复制代码

模块全局化

假设你在开发一个模块A，同时需要在另外一个项目B中测试它，当然你可以将该模块的代码拷贝到需要使用它的项目中，但这也不是理想的方法，可以在模块A的目录下执行：文章源自菜鸟学院-https://www.cainiaoxueyuan.com/gcs/13695.html

npm link
复制代码

npm link命令通过链接目录和可执行文件，实现任意位置的npm包命令的全局可执行。文章源自菜鸟学院-https://www.cainiaoxueyuan.com/gcs/13695.html

npm link主要做了两件事：文章源自菜鸟学院-https://www.cainiaoxueyuan.com/gcs/13695.html

  1. 为目标npm模块创建软链接，将其链接到全局node模块安装路径/usr/local/lib/node_modules/
  2. 为目标npm模块的可执行bin文件创建软链接，将其链接到全局node命令安装路径/usr/local/bin/

依赖锁定

npm默认安装模块时，会通过脱字符^来限定所安装模块的主版本号。可以配置npm通过波浪符~来限定安装模块版本号：文章源自菜鸟学院-https://www.cainiaoxueyuan.com/gcs/13695.html

npm config set save-prefix="~"
复制代码

当然还可以配置npm仅安装精确版本号的模块：文章源自菜鸟学院-https://www.cainiaoxueyuan.com/gcs/13695.html

npm config set save-exact true
复制代码

作者：HulkShen
链接：https://juejin.im/post/5d08d3d3f265da1b7e103a4d
来源：掘金
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。文章源自菜鸟学院-https://www.cainiaoxueyuan.com/gcs/13695.html

文章源自菜鸟学院-https://www.cainiaoxueyuan.com/gcs/13695.html
  • 本站内容整理自互联网，仅提供信息存储空间服务，以方便学习之用。如对文章、图片、字体等版权有疑问，请在下方留言，管理员看到后，将第一时间进行处理。
  • 转载请务必保留本文链接：https://www.cainiaoxueyuan.com/gcs/13695.html

Comment

匿名网友 填写信息

:?: :razz: :sad: :evil: :!: :smile: :oops: :grin: :eek: :shock: :???: :cool: :lol: :mad: :twisted: :roll: :wink: :idea: :arrow: :neutral: :cry: :mrgreen:

确定