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