分享一些 npm 包管理工具的實用小竅門，希望能夠略微提高下前端、Node.js 開發者的生活質量。
絕大多數前端和 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 webpack
webpack ...推薦：
npm i -D webpack
npx 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 run
Lifecycle scripts included in leancloud-realtime:
test
npm run lint && npm run build && npm run docs && npm run test:node && npm run test:browser
available 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猜猜輸入這個命令會得到什麼結果？你可以親自試一下。提示：這個命令完全沒有實用性可言。;-)