NPM實用指北

時間 2020-06-15

標籤 npm 用指简体版

原文原文鏈接

npm做爲下載node附送的大禮包，你們必定不會陌生。
然而關於npm，估計大量的只是用到npm install XXX以及npm run XXX。javascript

其實這裏邊還有不少有意思的命令&參數。
關於npm，大概有兩個做用：java

能讓咱們很方便的從網上下載第三方包進行實現功能
可以讓咱們本身編寫包，並上傳到網上供其餘人下載

下載相關的操做

下載主要就是圍繞着install這一個命令來的。node

install 能夠簡寫爲 i

安裝原有的依賴包

當咱們處於一個項目下時，執行npm i便可安裝當前項目全部的依賴包。
包含dependencies、devDependencies、optionalDependencies和bundleDependencies中的全部。
若是咱們在執行npm i時添加--production的參數，則表示是線上環境，將會忽略devDependencies下的全部依賴。git

如今咱們有以下的package.json文件：shell

{
  "dependencies": {
    "koa": "^2.5.0"
  },
  "devDependencies": {
    "eslint": "^4.19.1"
  }
}

若是執行npm i，則會安裝全部的依賴。npm

> npm ls --depth=0
├── eslint@4.19.1
└── koa@2.5.0

而後咱們再嘗試添加--production參數，使用--only=prod[uction]一樣能夠實現效果。json

> npm ls --depth=0
└── koa@2.5.0

使用--only=dev[elopment]則用來僅安裝devDependencies的依賴。bash

--depth=XXX 用來設置顯示路徑的深度，默認會遞歸將全部的依賴都打印出來。

新增依賴的安裝

上邊是直接安裝項目原有依賴的操做，若是咱們要新增一些依賴，這裏有一些選項能夠了解一下。
若是咱們在執行install添加--no-save、--save-dev之類的flag時，不會直接寫入到dependencies中，而是有一些其餘的處理。服務器

各類選項：koa

flag	description
`--save-prod`	默認選項對應`dependencies`
`--no-save`	不將依賴寫進`package.json`
`--save-dev`、`-D`	對應`devDependencies`
`--save-optional`、`-O`	對應`optionalDependencies`，在安裝時能夠經過指定`--no-optional`來忽略該模塊下的依賴
`--save-bundle`、`-B`	對應`bundleDependencies`，貌似已經被廢棄了-.-
`--save-exact`、`-E`	安裝精準的某個版本，在版本號處不會添加`^`之類的標識
`--global`、`-g`	全局安裝包，通常來講須要管理員權限

更多的參數請查閱：https://docs.npmjs.com/cli/install

在 package.json中常常能看到依賴的版本號前邊有一個 ^或 ~。
^和 ~會致使從新安裝依賴的時候，按照規則安裝最新版。
好比版本號爲 ^2.1.0，則會匹配 >=2.1.0 <3.0.0的全部包
若是版本號爲 ~2.1.0，則會匹配 >=2.1.0 <2.2.0的全部包
這兩個標識的好處是：一個包進行修復 bug，只更新了最後一位版本號，全部依賴它的包不須要從新上傳本身的 package.json
因此說，涉及到可能產生不兼容後果的更新，請必定要修改前兩位版本號。。不然就是坑人了-.-

以及咱們能夠指定安裝包時候的tag或者version

npm i koa@next
npm i koa@2.0.0
npm i koa@">=2.0.0 <2.5.0"

這裏的next就是一個tag 若是不指定的話，有一個默認的latest。
以及第二條指定安裝2.0.0版本的koa。
最後一條則會在範圍規則內選擇最新的版本進行安裝。

上傳相關的操做

要上傳，確定就要先進行開發。
因此咱們上傳的整個流程大概是這樣的：

npm init建立package.json
進行開發
npm show <你的包名>，若是404，那麼恭喜你，這個名字尚未被佔用。
npm publish，上傳包。

npm init

其實有不少狀況下，咱們建立package.json只是爲了安裝依賴，可是執行了npm init之後卻要確認好屢次選填內容。
其實若是你添加了一個參數之後，npm就不會讓你確認這些選填內容了。
npm init -f，--force、-y和--yes均可以實現這個效果。
固然，若是你是要將這個文件夾做爲一個pacakge發出去，則這些選填內容都是須要的。

開發包的過程

如何進行本地debug

在開發過程當中，爲了本地快速進行調試，能夠執行這樣的命令：
npm link <你的包名>
若是在當前包的文件夾中，能夠直接執行npm link

能夠簡寫爲 npm ln

而後在要調試的項目中執行npm link <你的包名>
便可建立一個引用本地的連接。
在調試完畢後，執行npm unlink來刪除連接。

如何建立命令行可執行模塊

咱們能夠在package.json中添加bin字段，用來指定一個文件。

{
  "bin": {
    "sayhi": "bin/hi"
  }
}

文件./bin/hi：

#!/usr/bin/env node

console.log('hi there')

若是用過-g進行全局安裝，就會註冊對應的命令，咱們在terminal中就能夠直接執行了。
#!/usr/bin/env node爲必須的，路徑可能會變

npm show

這個方法貌似沒有被寫在文檔裏。。但它確實是存在的。
執行npm show XXX會返回這個包對應的信息，也能夠直接在後邊按照JSON的格式來進行取值：

npm show koa version
npm show koa dist-tags.latest

npm publish

當咱們的包開發完畢後，就能夠執行publish來進行上傳了。

npm publish

你一樣能夠在後邊指定一個文件夾路徑或者壓縮包，但都須要這二者包含package.json文件（npm包的信息都在這裏）

以及，咱們能夠在後邊拼接--tag=XXX來上傳一個對應的tag，若是不寫的話，默認會上傳到latest下。
寫tag的好處是，咱們能夠同時維護多份代碼，二者互不影響（可是要當心publish的時候必定不要忘記tag）
就好比去年的node.js穩定版仍是6，可是koa已經開始使用7.6+的async/await特性，因此他們就發佈了koa@next，也就是如今的2.x，用來支持新的語法。

以後的版本更新

若是咱們的包放到線上之後，發現了bug，咱們須要修復它，由於npm的限制，因此每次publish必須保證version的一致性。
npm給咱們提供了這樣三個命令：

npm version patch
npm version minor
npm version major

三個命令依次會修改version的第3.2.1位。
major.minor.patch

patch

patch爲改動最小的，也就是咱們上邊提到過的bug修復，^和~都會兼容的版本號。

minor

若是是minor，則會修改中間的版本號，通常來說，新功能的增長鬚要修改這個版本號，由於可能會形成以前的使用方式改變。

major

最後一個則是很大的更新纔會去修改的版本號，例如咱們親愛的koa，在拋棄Generator擁抱async/await就是直接發佈了koa2.x。

執行這三個命令的先提條件是，你當前倉庫是不存在未提交的修改的。
由於npm會直接幫你修改version並增長一條commit記錄，若是有未提交的修改，可能會致使版本衝突。
在執行完這些命令（或者手動修改版本號也是沒問題的），再執行npm publish便可上傳更新包了。

若是想要自定義此次提交的信息的話，能夠這樣：
npm version patch -m "Upgrade version to %s"
%s會自動被 npm替換爲更新後的版本號提交上去。

更新時必定記得加對應的--tag，不然默認會推到@latest上

npm scripts

關於package.json中的scripts，不知道你們瞭解多少。
若是你的包是上傳到npm上的，那麼其實有不少scripts是相似鉤子的存在。

publish

當你的包執行了publish上傳到服務器後，這個腳本會執行。
其實咱們能夠在這個地方執行git push操做來將本次的修改直接推到GitHub倉庫上，節省了一次沒必要要的命令鍵入。
或者若是你這個包同時還上傳到apm或者之類的同類型倉庫，也能夠直接在這裏進行處理（省去屢次繁瑣的操做）