npm常用命令及版本號淺析
npm 包管理器的常用命令
測試環境為node>=8.1.3&&npm>=5.0.3
1, 首先是安裝命令
//全域性安裝
npm install 模組名 -g
//本地安裝
npm install 模組名
//一次性安裝多個
npm install 模組1 模組2 模組3
//安裝開發時依賴包
npm install 模組名 --save-dev
//安裝執行時依賴包
npm install 模組名 --save
2, 檢視安裝的目錄
//檢視專案中模組所在的目錄
npm root
//檢視全域性安裝的模組所在目錄
npm root - g
3, 檢視npm的所有命令命令
npm help
4,檢視某個包的各種屬性
//檢視某個包對於各種包的依賴關係
npm view 模組名 dependencies
5,檢視包的原始檔地址
//檢視包的原始檔地址
npm view 模組名 repository.url
6
檢視當前模組依賴的node最低版本號
npm view 模組名 engines
檢視模組的當前版本號
npm view 模組名 version //需要注意的是檢視到的模組版本是該模組再遠端倉庫的版本號,並不是當前專案中所依賴的版本號。
檢視模組的歷史版本和當前版本
npm view 模組名 versions
檢視一個模組的所有資訊
npm view 模組名
7,檢視npm使用的所有資料夾
npm help folders
8,用於更改包內容後進行重建
npm rebuild 模組名
9,檢查包是否已經過時
//此命令會列出所有已經過時的包,可以及時進行包的更新
npm outdated
10,更新node模組
npm update 模組名
//當然你也可以update 該模組到指定版本
npm update 模組名 @版本號
//如果安裝到最新版本可以使用以下命令
npm install 模組名@latest
//如果當前的版本號為2.5.1,是沒辦法進行npm update 模組名 @2.3.1 將模組版本號變為2.3.1的,當然,你可以先uninstall,然後進行install @2.3.1
11,解除安裝node模組
npm uninstall 模組名
12,訪問package.json的欄位文件
npm help json
13,釋出一個npm包的時候,需要檢驗某個包名是否已經存在
npm search 模組名
14,npm init:引導你建立一個package.json檔案,包括名稱、版本、作者這些資訊
清除npm的快取
npm cache clean //慎重使用改命令
15, npm root 檢視當前包的安裝路徑,
npm root -g 檢視全域性的包的安裝路徑
16,npm -v 檢視npm的版本
17,檢視某個模組的bugs列表介面
npm bugs 模組名
//例如執行npm bugs chai則會開啟vue倉庫的issue,效果如下圖
18,開啟某個模組的倉庫介面
npm repo 模組名
//例如執行npm repo vue則會開啟vue線上倉庫,效果如下圖
開啟某個模組的文件
npm docs 模組名 //例如執行npm docs vue則會開啟vue的readme.md文件
開啟某個模組的主頁
npm home 模組名 //例如執行npm home vue則會開啟vue模組的主頁
檢視當前已經安裝的模組
npm list //當然我們也可以限制輸入的模組層級,例如 npm list --depth=0
清除未被使用到的模組
//有時在我們使用npm list的時候,可能會碰到一些問題,就是有些模組並沒有被專案引用使用,我們還是安裝了這些模組,那麼我們可以一鍵清除這些沒有使用到的模組 npm prune
版本控制
我們使用node開發時,經常需要依賴一些模組,我們進行了下載之後,便一直在該版本的模組環境下進行開發,但是線上的伺服器一般都是根據依賴來配置檔案,重新下載各個模組,但是保不齊某個模組的版本已經更新了,這時線上的包會更新到最新的版本,但你的程式碼還是依據老版本來寫的,這時可能會產生一些不知名的Bug,
首先看npm包的版本號的格式X.Y.Z,版本好的格式遵循semver 2.0規範,其中X為主版本號,只有更新了不向下相容的API時進行修改主版本號,Y為次版本號,當模組增加了向下相容的功能時進行修改,Z為修訂版本號,當模組進行了向下相容的bug修改後進行修改,這就是“語義化的版本控制”。
預設情況下,當用--save或者--save-dev安裝一個模組時,npm通過脫字元(^)來限定所安裝模組的主版本號,而該脫字元對於不同的版本號有不同的更新機制
- ^1.2.1 代表的更新版本範圍為 >=1.2.1 && < 2.0.0
- ^0.2.1 代表的更新版本範圍為 >=0.2.1 && < 0.3.0
- ^0.0.2 代表的更新版本範圍為 0.0.2(相當於鎖定為了0.0.2版本)
##### 對於上述字元的版本控制,我們可以來進行一個嘗試:
首先可以看到package.json中對於vuex的版本依賴為^2.3.1
然後檢視以下專案中安裝的vuex模組的版本號
果然沒錯,改版本號為2.3.1,接下來我們看一下vuex的歷史版本(npm view vuex versions)
可以看到2.3.1-2.5.0之後到了3.0.0,接下來執行npm update vuex,檢視以下更新後的版本
現在我們看到更新後的vuex版本號為2.5.0 < 3.0.0,可以驗證第一條規範。
我們再來驗證下主版本號為0的版本控制情況,先將當前專案依賴的vuex版本改為@0.6.1版本.
npm uninstall vuex
//解除安裝vuex成功
npm install [email protected]0.6.1 --save
//安裝vuex0.6.1版本成功
然後更新當前專案中的vuex版本,執行程式碼 npm update vuex
可以通過npm view vuex versions看到vuex的版本歷程,在0.6.3之上為0.7.0,所以當使用脫字元(^)來控制版本號時,當主版本號為0,即代表該模組在快速構建中時,更新專案時的版本範圍只能更新修訂版本號Z。
對於第三種情況,當主版本和此版本都為0時,代表著該模組處於一個極其不穩定的狀態,在執行update時並不會進行版本更新。
波浪號(~)是限定模組的次要版本,(以下規則測試方法同上,便不一 一測試)
- ~1.5.1允許安裝版本號大於1.5.1但小於1.6.0版本的模組
- ~0.5.1允許安裝版本號為0.6.0
當主版本號/次版本號/修訂版本號為X or x or *時,那麼update或install是會下載該分支最新的版本號
- (*)跟新或安裝模組時會安裝>=0.0.0的最新版本
- 1.x 表示的更新範圍為>=1.0.0&&< 2.0.0
- 1.2.x 表示的更新範圍為>=1.2.0&&< 1.3.0
1,當然我們也可以把專案依賴的包固定在某一個版本,強制大家安裝相同的依賴樹,如下所示:
npm install react --save -E
//此命令會將react的版本號進行固定,但是該方式只能控制專案中直接依賴的包的版本,無法控制專案模組中依賴的包的版本號,所以這種方式也無法讓不同的使用者得到相同的依賴樹。
2,此外我們還可以使用npm shrinkwrap,可以將專案中的模組版本進行精確鎖定:
這時候只需要執行命令 npm shrinkwrap,便會產生一個npm-shrinkwrap.json檔案,這個檔案儲存了所有當前使用的依賴模組的版本:把該檔案提交到git倉庫中,這樣其他人在clone你的專案的時候,執行npm install命令時,npm檢測到該檔案中的資訊會完整的還原出完全相同的依賴樹,具體的使用方法如下:
npm install --save-dev react //安裝react
npm prune //清除未被使用的模組
npm shrinkwrap
但是使用這種方法,安裝一個模組包的方式比較繁瑣。
3,使用yarn我們也可以得到模組包精確控制的結果
yarn是一個與npm相容的node包管理器,使用它安裝npm包,會自動在專案目錄建立一個yarn.lock檔案,該檔案包含了當前專案中所安裝的依賴包的版本資訊,其他人在使用yarn安裝專案的依賴包時就可以通過該檔案建立一個完全相同的依賴環境。
使用方法如下:
yarn init //使用yarn建立一個專案
yarn add 模組名 //使用yarn 安裝一個包
//還有很多yarn命令
此外,yarn除了可以自動幫我們鎖定依賴包的版本,yarn還在本地快取已經安裝過的包,當再次安裝時,直接從本地讀取即可。安裝速度得到大大提升。但yarn的使用需要整個團隊都去使用,還是有一定的成本的。
綜上所述,目前大多數專案中較為簡單的使用規範,在專案中依賴各個模組時,對於主版本號和次版本號都為0的不穩定的專案,我們可以使用精確版本(exact),對於主版本號為0次版本號不為0的模組和主版本號不為0的模組,使用caret Range即脫字元(^)來控制版本。當然,我們也可以對專案依賴模組的版本進行精確鎖定。
SemVer(Semantic Versioning) 2.0.0
SemVer是一個對npm包版本進行規範的模組,它對於npm包的版本號有著一系列的規則,以下為摘抄自SemVer 2.0.0中的規則:
- 在版本控制環節我們已經說過了,模組的版本號採用X.Y.Z的格式,且都必須為非負的正整數,依次為主版本號、次版本號,修改版本號。
- 當規定版本的模組進行釋出之後,對於該模組的任何修改,都必須釋出新版本。
- 主版本號為0.X.Y的模組處於開發階段,模組並不穩定。
- 主版本號在有不向下相容的API釋出時必須修改,在主版本號遞增時,次版本號和修訂版本號必須重新歸零。
- 次版本號再有向下相容的API釋出時進行遞增修改,在模組中有API被棄用時也必須遞增次版本號,當此版本號遞增改變時,修訂版本號Z必須歸零。
- 版本的優先順序就是各個版本的排序規則,判斷版本優先順序時,必須把版本號從左至右分為主版本號、此版本號、修訂版本號、以及先行版本號來進行比較