npm相关知识点总结

前言

本文总结了工做中经常使用到的以及一些不经常使用容易忽略的npm知识，包括:

1. npm 各类基本命令及做用
2. package.json 的各字段详解
3. 版本号详解
4. npm3.x安装依赖包的规则
5. 关于npm源的解释与设置
6. pacak-lock.json的解释与做用

基本命令速览

描述	命令
查看npm版本	npm -v
初始化项目（生成package.json）	npm init
查看全部全局安装的包	npm list -g
查看包的版本号	查看包的全部版本（远程） npm view <Package Name> versions 查看包的最新版本 npm view <Package Name> version 查看包的版本及其余信息 npm info <Package Name> (在包文件夹下打开终端时能够直接输入npm info)
查看当前登录的npm帐号	npm whoami
登录npm	npm login 若是须要切换用户，只须要执行此命令从新登录便可完成切换
注册npm	npm adduser
安装pacakge.json中的依赖包	npm install
安装第三方npm包	全局安装 install <Package Name> -g 本地安装 npm install <Package Name> 安装指定版本包 npm install <Package Name>@xx.xx.xx 安装最新版或tag版 npm install <Package Name>@latest npm install <Package Name>@beta beta为发布的tag版名称 安装并写入package.json的dependencies(生产环境依赖） npm install <Package Name> --save 安装并写入package.json的devDepencies中（开发环境依赖) npm install <Package Name> --save-dev 安装固定版本号 npm install <Package Name> --save-exact
更新包	更新某个包 npm update <Package Name> 更新包的同时更新package.json文件中对应包的版本信息npm update <Package Name> --save
删除包	删除全局包 npm uninstall <Package Name> -g 删除包的同时删除留在package.json中dependencies下的包 npm uninstall <Package Name> --save 删除包的同时删除留在package.json中devDependencies下的包 npm uninstall <Package Name> --save-dev
修改源	npm config set registry https://registry.npm.taobao.org 查看源 npm config get registry
管理包做者	添加包做者 npm owner add <user> <Package Name> 删除包做者 npm owner rm <user> <Package Name> 查看包全部的做者 npm owner ls <Package Name> （owner或author都可）
发包	在当前目录下打开终端 发布正式版 npm publish 发布tag版（tag名称随意） npm publish --tag beta
连接其余包 当咱们本地开发npm包时，通常该包的位置并不在项目目录中，为了方便开发，可使用npm link将该包连接到项目中，方便开发调试。（注：尽可能不要直接在项目的node_moudles中建立本地包进行开发，若是package.json中没有写依赖，很容易在更新其余包的时候形成本地包丢失，血泪的教训……😢)	npm link 1, 在本地包test包打开终端执行npm link将包连接到全局 2，在项目根目录下执行npm link test将包连接到项目中

pacakge.json

npm init 会建立package.json文件 官方文档

• name

包的名字（必填字段），
· 名称必须少于或等于214个字符，
· 不能以'.'或者'_'开头,
· 名称中不能包含大写字母，
· 必定要简短并高度归纳，
· 不能和npm其余包重名，不然发布不成功
· 名称能够带前缀，eg. @babel/cli 安装以后的目录以下：

• version

版本（必填字段）
版本号由三个数组用.隔开分别是[大版本，次要版本，修复版本]
大版本： 版本有重大升级，不向下兼容，升级需谨慎。eg. react@15.x和react@16.x、webpack@3.x和webpack@4.x
次要版本：版本有新功能，并向下兼容，能够随时更新。
修复版本：版本主要修复了bug，能够随时更新。

1. "latest": 最新版,npm i时会安装最新的大版本，绝对不要用这个，很是不安全
2. "beta|test|alpha": 默认安装最新的tag版，关于发布tag的规范能够参考semver
3. "1.0.0": 精准匹配版本号
4. "^1.0.0": 匹配2，3级版本。eg. 能够匹配大于等于1.0.0小于2.0.0的版本
5. "~1.0.0": 匹配3级版本。eg. 能够匹配大于等于1.0.0小于1.1.0版本,但匹配不到1.1.0版本
6. "~1.2.3-beta.1"： 匹配大于等于1.2.3-beta.1小于1.3.0的版本，可是须要注意的是若是是beta版，只能匹配大于等于1.2.3-beta.1小于1.2.4-beta.1的版本。也就是说beta版本前缀不能大于1.2.3，正式版能够大于1.2.3小于1.3.0
7. ">1.0.0": 匹配大于该版本的。
8. ">=1.0.0": 匹配大于等于该版本的。
9. "<1.0.0": 匹配小于该版本的。
10. "<=1.0.0": 匹配小于等于该版本的。
11. "=1.0.0": 匹配等于该版本的，和不加"="的状况同样。
12. ">=1.0.0 <2.0.0": 匹配大于等于1.0.0，小于2.0.0的。
13. "1.3.4 || >=1.0.0 <2.0.0": 匹配1.3.4或大于等于1.0.0，小于2.0.0的。
14. "1.0.0-beta.1"：tag版，若是不当心将tab版本执行了npm publish 发布成了正式版，这时只要执行 npm dist-tag add 1.0.0-beta.1 latest便可把该tag版转为正式版
15. "1.2.3 - 2.3.4": 匹配1.2.3到2.3.4之间的版本， 若是只提供了一级或二级版本则匹配一级或二级最大版本。
    eg. 1.2.3 - 2 -->匹配大于等于1.2.3小于3.0.0的版本。
16. "1.x": 匹配大于等于1.0.0小于2.0.0的版本,等同于"^"
17. "1.2.x"： 匹配大于等于1.2.0小于1.3.0的版本,等同于"~"
18. "*"： 匹配任何版本
19. ""： 匹配任何版本,等同于*
20. "1"： 匹配大于等于1.0.0的版本，等同于1.x
21. "1.2"： 匹配大于等于1.2.0的版本，等于1.2.x

• description|keywords

包的描述/关键词,能够经过npm search来搜索

• main

包的入口文件，默认为index.js，
browser 环境和 node 环境都可使用

• author

包的做者

• scripts

用来定义一些脚本命令命令如：start,dev,build等

• repository

代码存放的地方type能够是svn或git
url为访问路径

"repository": { 
    "type" : "git", 
    "url" : "https://github.com/npm/cli.git" 
}

• maintainers

包的全部者列表，经过npm owner add添加的都会出如今此列表

• homepage

项目主页地址

• bugs

项目问题的提交地址

• license

包的证书，指定了使用者使用的的权限

• files

一个文件类型的数组，用来表示在当前包做为依赖包时安装并显示的目录，语法相似于.npmignore 文件，表示含义恰好相反，.npmignore 里的表明安装时要忽略的；写入flies的表明安装时不忽略的

• browser

指定该包在客户端使用

• bin

指定script字段中的命令的执行文件
eg. { "bin" : { "myapp" : "./cli.js" } } 这样在script能够简写成: script:{"start": "myapp start"}
注：确保引用的文件（cli.js）头部引入#!/usr/bin/env node

• man

man是manual的缩写，man命令用来查看帮助文档的，如Linux中的命令帮助、配置文件帮助、编程帮助等信息，咱们在package.json中配置以后，那包安装以后能够经过man <Pacakge Name>来查找到包中的帮助文档。
附上官网例子：

{ 
    "name" : "foo" ,
    "version" : "1.2.3" ,
    "description" : "A packaged foo fooer for fooing foos" ,
    "main" : "foo.js" ,
    "man" : "./man/doc.1" 
}

以上代码执行man foo 能够查找到./man/doc.1文件内容

若是文件名不是以包名开始的，则man 命令会自动建立前缀，以下：

{ 
    "name" : "foo" , 
    "version" : "1.2.3" , 
    "description" : "A packaged foo fooer for fooing foos" ,
    "main" : "foo.js" , 
    "man" : \[ "./man/foo.1", "./man/bar.1" \] 
}

以上代码会建立man foo和 man foo-bar命令来查询文件

文件须要以数字结尾，或者当文件压缩时以 .gz结尾，数字表明的是文件安装在man命令的哪部分。

• directories

目前这个配置没什么用

• config

能够用config在package.json中设置一些不会变化的配置参数，详情请查看npm-config, 附上官网的例子：

{ "name" : "foo" , "config" : { "port" : "8080" } }

而server.js是这样的：

http.createServer(...).listen(process.env.npm_package_config_port)

那么用户能够经过如下方式更改行为：

npm config set foo:port 80

• dependencies

当前包的依赖包，生产环境须要打包在项目中时使用（eg. react、vue、antd等须要打包后在生产环境使用的包）。能够是具体的包，也能够是git地址或压缩包。经常使用的一些例如：

"dependencies": {
    "prop-types": "^15.7.2",
    "react": "~16.8.6",
    "react-dom": "latest",
    "easy-danmaku": "/Users/jamie/work/fe/cnpm/danmaku",
    "xxx": "git+https://github.com/xxx/xxxx.git"~~~~
},

在咱们执行npm i时可能会遇到这样的现象，

1. A包中的依赖B包为何安装后在node_modules里A包，B包都同级了，B包并无安装在A包的node_modules里？
2. 为何A包中依赖B包，c包也依赖B包，为何安装后有时候C包和A包、B包同级，有时候又分别安装到各自的node_modules里了？

在解释这个问题以前，能够先查看一下本身的npm 版本号，npm -v 若是npm版本号大于3.x, 这个版本的npm采用了包管理因此会出现上面说的现象。若是版本为npm2.x，属于嵌套模式，全部包的依赖包都会分别打包在本身的node_modules中，形成嵌套过深的问题。这里咱们主要说npm3.x的包管理，若是A包，B包依赖的C包版本相同，则安装后会平铺在node_modules里，若是版本不一样则会分别打包到各自的node_modules里。

注：在使用过程当中发现，依赖包版本号为beta时，不会扁平化安装，若是须要扁平化安装须要写版本号或latest,这就形成了另外一个版本冲突的问题，这时使用peerDependency更合适，下文会详细说明

• devDependencies

开发环境须要使用的工具类依赖包（eg. babel、webpack、eslint、typescript等须要在开发中用到的打包，编译，检测等工具包）。

• peerDependencies

提示安装时须要将peerDependencies中的依赖做为项目依赖安装。 在npm3.x后，若是包的依赖为peerDependencies，则会在安装过程当中提示须要手动安装peerDependencies的依赖。做用是防止项目已经依赖了C包，安装的A包中也依赖了C包。两处的C包因版本不一致而致使的问题。

• optionalDependencies

可选依赖包，用来放一些不阻断项目正常运行的插件包，即便这些包安装失败也不会阻塞npm的继续执行。须要注意的是optionalDependencies里的包会覆盖dependencies里的

• bundledDependencies

捆绑组件包，打包后会将依赖包一并打包进去，安装时只需安装一个包便可，须要注意的是bundledDependencies中的依赖包须要先在dependencies或devDependencies中定义，在执行npm pack的时候才会打包进去

• publishConfig

发包时设置该包发布的仓库地址，通常公司有内部私有仓库时，这里设置为该仓库地址。

"publishConfig": {
    "registry": "http://xxx/xxxx/repository/cnpm/"
  }

咱们公司也有内部仓库可是发包是并不须要设置publishConfig，而是全部包都是在一个做用域下，例如： @babel/core的形式

publishConfig决定发包到哪，.npmrc决定从哪安装。 关于.npmrc的详细解释与用法请看下文。

• engines

指定包的运行引擎。
eg.

{ "engines" : { "node" : ">=0.10.3 <0.12" } }
// or
{ "engines" : { "npm" : "~1.0.20" } }

指定该包只能在node版本大于等于0.10.3小于0.12或npm版本大于等于1.0.20小于1.1.0的版本上运行）

• os

指定包运行的操做系统。
eg.

{"os" : [ "darwin", "linux" ]}

或者指定不能在某些操做系统运行

{"os" : [ "!win32" ]}

• cpu

指定包运行的cpu
eg.

{"cpu" : [ "x64", "ia32" ]}

或则指定不能在某些cpu运行，相似os

• private

若是设置为true，npm publish时会没法发布，这是为了防止将不能发布的包误发布，没什么用处

package.json中还能够添加一些非官方的工具类配置。
eg. 当咱们查看antd的package.json时会发现有一些并非官方文档里的，有一篇文章总结的很不错，点击这里看 非官方配置

npm 其余知识点

npm源

说到npm源就须要介绍一下.npmrc文件，文件主要是用来设置npm源的，npm默认都是指向https://registry.npmjs.org/ 可是为了提高安装速度，须要设置源为https://registry.npm.taobao.org/ 可是当咱们依赖包里又有npm包，又有公司私有仓库包时，须要将某些包的npm源指向公司私有仓库地址。拿咱们公司举例，假设咱们的npm包做用域为@test 我须要将@test下的包的源指到公司仓库地址,这样我执行npm i时能够同时安装npm上和公司内部的包

npm config set @test:registry http://registry.xxxx.xxx.com

npm config set实际上是在.npmrc中设置了源，若是想直接打开文件设置，能够执行npm config ls -l找到.npmrc文件的位置进行

或者在终端直接执行npm config edit进行编辑
推荐一个好用的随时切换npm源的工具nrm

package-lock.json

咱们常常会发如今执行npm i时会默认在根目录生成package-lock.json文件，打开查看会发现都是咱们一些依赖包的相关信息

package-lock.json是用来锁定版本的，也就是说每次安装都会默认安装package-lock.json中的版本，若是多人开发，能够保证版本一致。
注：若是手动修改了package.json中的版本号，直接执行npm i后发现安装的并非package.json中的版本号，这时须要删除package-lock.json文件再安装，或直接安装某个特定包

Reference

npm官方文档：
https://docs.npmjs.com/cli-documentation/
https://docs.npmjs.com/files/package.json.html