前言

絕大多數前端和 Node.js 開發者每天的日常工作都離不開 npm，不知道你對 npm 的觀感如何？如果你覺得 npm 很棒，那么不妨看下這篇文章，說不定其中有你之前沒留意過的小竅門，可以讓你 npm 用得更順手。如果你覺得 npm 很糟糕，那也可以看下這篇文章，也許會發現用上一些小技巧，npm 會變得稍微不那么糟糕。

npm ci

別被它的名字騙了。npm ci 并不僅僅適用于持續集成系統，在日常開發中，npm ci 非常實用。和 npm install 不同，npm ci 根據 package-lock.json 安裝依賴，這可以保證整個開發團隊都使用版本完全一致的依賴，避免把時間浪費在排查因為依賴不一致而導致的各種奇怪問題上。不僅如此，npm ci 還有一個很好的副作用，加快 node 模塊安裝速度。因為 npm ci 直接根據 package-lock.json 中指定的版本安裝，無需計算求解依賴滿足問題，在大多數情況下都可以大大加速 node 模塊安裝過程。如果你曾經因為嫌 npm install 太慢而換用兼容性不那么好的 yarn 以及兼容性更不好的 pnpm，那么不妨試下 npm ci，也許你會發現，其實 npm 也可以不那么慢。

另外，如果 package-lock.json 過時（和 package.json 沖突），那么 npm ci 會很貼心地報錯，避免項目依賴陷入過時狀態。

有了 npm ci，基本上我只在引入新依賴時才使用 npm install。

注意，npm ci 在安裝前會自動清除現存的 node_modules，所以 npm ci 天然規避了增量安裝可能帶來的不一致性等問題。（這也意味著，你又可以少記一條命令 npm prune。）不過，如果你的網絡很慢，那可能就不那么妙了。別慌，你可以用 --prefer-offline，最大限度地利用 npm 的全局緩存加速安裝過程。

當然，既然使用 npm ci，那就別忘了把 package-lock.json 加入 git 倉庫。

npm outdated

npm ci 基于 package-lock.json 鎖定依賴版本，確保項目開發環境的一致性。但這并不意味著依賴版本是鎖死的。為了利用新版本帶來的問題修復、新特性以及性能提升，定期還是需要升級依賴版本的。在這一場景下，推薦使用 npm outdated。它會列出還沒有升到當前最新版本的項目依賴。紅色表示符合指定的語義化版本范圍，理論上可以無腦升級（npm update 會一次性升級所有紅色依賴）。黃色表示不符合指定的語義化版本范圍，比如大版本升級，升級可能會遇到兼容性問題。

有些項目處于維護階段，不打算加新特性了，甚至可能不太嚴重的問題都不打算修復了，但是像安全漏洞這樣的嚴重問題還是要管的。這時可以使用 npm audit 命令，列出項目依賴中有安全漏洞的版本。處于活躍開發階段的項目當然也需要關注安全漏洞問題，但是因為 npm install 引入新依賴時會自動運行 npm audit，再加上會定期運行 npm outdated，所以手動運行 npm audit 的機會不太多。

npx

前面說過基本上只在引入新依賴時才使用 npm install，沒有提到全局安裝。全局安裝當然也需要使用 npm install。不過，為了確保開發環境的一致性，npm install --global 應當慎用。個人建議僅僅在安裝一些日常使用的工具時才使用全局安裝，而項目開發所需的工具，則作為開發依賴安裝，然后使用 npx 調用。

不推薦：

npm install --global webpackwebpack ...

推薦：

npm i -D webpacknpx webpack ...

這里 i -D 是 install --save-dev 的簡寫形式。

對于一些一次性的臨時任務，可以直接通過 npx 運行相應工具，免去了手動安裝的麻煩，也不會污染 devDependencies。

例如，之前項目使用 webpack 打包，現在想臨時試下換用 rollup 打包的效果：

npx rollup ...

npx 很智能，如果路徑中找不到 rollup，會自動安裝。

npx 用來測試不同版本的兼容性時非常好用。下面是一些例子。

需要用到的 cowsay 的某個特性或修復已經合入 GitHub 主線，但是還沒在 npmjs 上發新版，試一下：

npx github:piuccio/cowsay

臨時測下內部維護的 cowsay 的一個分支：

npx git+ssh://my.hosted.git:cowsay.git#semver:^1

當前使用的是 node 的 LTS 版本（10），想試下 node 12 下構建腳本能不能跑起來：

npx -p node@12 npm run build

從上面我們可以看到，當包名和命令名不同時（npm 命令由 node 提供），可以用 -p 選項指定包名。

npm run

在 package.json 的 scripts 屬性中加入命令（例如："foo": "echo foo"）就可以通過 npm run foo 運行對應命令。這是 npm 提供的一個很方便的運行項目相關的自動化任務的機制，有一點類似 make。不過直接運行 make （不帶任何參數）會運行默認任務，但直接運行 npm run （不帶任何參數）會列出所有在 scripts 中聲明的命令。

; npm runLifecycle scripts included in leancloud-realtime: test npm run lint && npm run build && npm run docs && npm run test:node && npm run test:browseravailable via `npm run-script`: precommit pretty-quick --staged commitmsg commitlint -e $GIT_PARAMS lint eslint --ignore-path .gitignore src test plugins && tsc realtime.d.ts --strict ...

其他

這里還有一些我個人覺得不是特別實用的小竅門，不過，每個人的需求和偏好不同，說不定你會覺得它們挺有用的。如果你有想要分享的竅門，歡迎留言。

• npm init -y 默認情況下，npm init 會讓你回答一些問題。npm init -y 可以跳過這些問題，直接上手開發。我之所以不推薦它，是因為，如果你打算盡快上手開發一個應用，絕大多數情況下會用框架，而幾乎所有框架在 npmjs 上都至少有一個 create-xxx-app 包。所以基本上你沒有機會輸入 npm init 去回答那些問題。而如果你打算寫一個組件或庫，那么 package.json 中的元信息對組件或庫的使用者很重要（即使是僅供你自己使用的組件或庫，未來的你也未必記得當初寫這個組件或庫的上下文），跳過這些問題并不是一個好主意。當然，急躁是程序員的三大美德，你也許會想，我可以在完成開發后再來補這些。但是，一般來說，往往項目開始的時候是你最有興趣（或者說，稍微不那么反感）記錄這些上下文的時刻。如果在項目開始的時候都不耐煩做這個，開發完成后，很可能就更沒興趣了。同理，README 也應該在項目開始前寫。
• npm repo 可以打開項目的源代碼倉庫（大部分情況下是 GitHub），它還有一個姊妹命令，npm home，可以打開項目的主頁。不過，我個人覺得，比起這兩個命令，通常而言， IDE 或者編輯器的智能提示（速覽類型、速覽文檔、速覽定義之類）更高效。
• .npmignore 文件可以列出不想打包的文件，避免把一些無關的文件發布到 npmjs 上。但是，統一使用 .gitignore 可以滿足絕大部分場景下的需求。而且，只存在 .gitignore 的情況下，npm publish 會尊重 .gitignore 的聲明，而 .npmignore 和 .gitignore 同時存在的情況下，npm publish 會忽略 .gitignore，而不是取兩者的并集。換言之，.gitignore 中忽略但 .npmignore 中未忽略的文件會被打包發布。所以，使用 .npmginore 就意味著需要同時小心翼翼地維護兩份大部分內容重復的列表。同時，一旦團隊中有任何一人因為偶然的疏忽或者不熟悉 .npmignore 和 .gitignore 關系的細節出現了失誤，那就有可能將敏感信息發布到 npmjs 上，導致安全事故。
• 各種 npm 命令的快捷版本，比如上文用到的 npm i -D。這些個人覺得不用專門刻意去記。經常輸入的命令，可以 npm help 一下看看有沒有簡短版本。不查也沒有關系，npm t 和 npm test 乃至 npm run test 的區別絕不是開發效率的瓶頸所在。很多時候這只是個人偏好問題，比如追求盡可能少打字的人會喜歡 npm t，追求盡可能少記東西的人會喜歡 npm run test （永遠不會因為誤以為 npm build 表示 npm run build 而碰到問題），其他人可能會喜歡 npm test 這樣中庸的選項。
• npm xmas 猜猜輸入這個命令會得到什么結果？你可以親自試一下。提示：這個命令完全沒有實用性可言。;-)

總結

以上就是這篇文章的全部內容了，希望本文的內容對大家的學習或者工作具有一定的參考學習價值，謝謝大家對武林網的支持。