前端 npm 安裝包，精選大全

如果你曾在 Node 或 JavaScript 前端開發中投入過時間和精力，那麼你就知道 npm 中有數以十萬計的模塊可供您選擇

通常在提出這樣的問題時，你會得到十個不同的答案。每個人都會給你推薦自己喜歡的模塊，接下來就演變成爭論哪一個是最好的。

選擇 npm 模塊時很容易面臨紙上談兵。選擇太多，而新來者在鼓吹“快上車”，爲您的項目選擇合適的 npm 模塊可能是有難度的。而且這些模塊中有許多做類似(或相同)的事情，這也沒有幫助。

與其浪費時間在 google 上搜索，在 npmjs.org 上搜索，或者浪費更多的時間不構建您的項目，還不如搞清楚什麼時候該選擇哪些模塊。

精選清單

爲了幫助解決這個問題，你將在下面找到針對最常見問題類型(即 web 框架、模板、身份認證等)的 npm 模塊列表，以及何時使用這些模塊。

這裏有一些注意事項：你可能熟悉其中一些模塊，甚至許多模塊，但是有時候您面對的是你還沒有接觸到的技術棧(可能是身份驗證或 Websocket 之類的東西)，你需要知道有哪些備選模塊可以完成這項工作。你可能有你認爲更好的模塊，或者可能有一個用例/需求沒有包含在這裏。

我沒有列出相同類別的 10 個不同模塊，而是縮小了範圍，這樣你就可以避免分析癱瘓的陷阱。如果你認爲自己的用例未被涵蓋，請務必自行研究解決。本清單的目的在於讓你能更快地啓動和運行。

這些模塊的選擇依據如下:

• 它們完成工作的能力如何
• 社區規模（對於支持/故障排除很重要）
• 積極維護

如果你發現自己仍然沒有足夠的信息做出決定，我建議使用slant.co和nodejs.libhunt.com來幫助進行比較。

注意:爲了保持範圍的合理性，這些模塊都考慮到了服務器端。它們中的一些可以同時在客戶機或服務器上使用，但我的原則是“服務器優先”。

HTTP requests (HTTP 請求)

• Request:
• 當你需要基於回調的 HTTP 請求時可選擇它，例如從一個 REST 服務連接到另一個。
• Axios
• 當你需要基於 Promise的 HTTP 請求時可選擇它
• 注意:你可以使用request-promise，但是 axios 的依賴更少，並且基於原生 Promises

Web frameworks (Web 框架)

• Express:
• 如果你想爲 API、網站或單頁應用程序使用輕量級 web 框架，請使用它
• 你不介意使用回調作爲默認的異步處理方式
• 使用該框架的模塊生態極爲繁榮
• 你需要一個支持和故障排除的大型社區
• Koa:
• 當你想要一個比 Express 更簡潔的框架時使用
• Koa 更像是一箇中間件層，它不提供模板或開箱即用的路由，因此更適合 API 開發
• 要想支持開箱即用，你需要 async / await
• Hapi
• 如果你想要一個比 Express 或 Koa 更“自帶電池”的框架，但又不像 Sails 那麼多，那就使用它
• Sails
• 當你需要像 Rails 這樣的東西時，請使用它，它具有幾乎所有功能(但是根據你的應用程序可能不需要那麼多)

Validation (前端驗證)

• Ajv
• 在需要驗證 JSON 時使用(比如來自 web 請求)
• 你希望與應用程序的其他非 JS 部分共享這些驗證規則(因爲它是 JSON，所以你可以這樣做)
• Joi
• 在需要驗證輸入時使用，並且喜歡鏈式調用的風格(譯者注:代碼見下方)，而不是在 JSON 中定義驗證規則
• 你正在使用 Hapi（Hapi 自帶 Joi）

const schema = joi.object().keys({
  id: joi.string().guid().required(),
  username: joi.string().alphanum().min(8).required()
});

Authentication (身份認證)

• Passport:
• 當你需要爲您的網站或 API 使用身份驗證中間件時使用
• 你希望能夠在多種身份驗證類型（Oauth，Facebook 等）之間進行選擇
• 你需要管理會話

Asynchronous (異步)

• Async (library):
• 當你需要使用舊版本的 Node，而該版本的 Node 支持只支持回調而不支持 Promises 時
• ES6 原生 promises (原生 JS, 非 npm):
• 在使用大於 0.12 的 Node 版本時使用
• 另一件需要考慮的事情是你的團隊對 Promises 的接受程度。
• async / await（原生 JS，非 npm）
• 當你爲了逃脫“回調地獄”卻又誤闖“Promise 地獄”
• 你有很多來自 Promises 的.then 和.catch

Database (數據庫)

下面是數據庫驅動程序、ORM 和查詢生成器的組合。在使用 ORM 之前，我強烈建議你首先確保需要使用它。當你可以只使用原始 SQL 或查詢生成器時，它們通常會添加另一層抽象，這層抽象不一定能夠提供足夠的回報。

• mysql, node-postgres:
• 當你不需要完整的 ORM，而是需要使用原始 SQL 查詢數據庫時使用(這些是驅動程序)
• node-mongodb-native:
• 當你不需要一個完整的 ORM，而是要直接查詢 MongoDB 時使用
• Mongoose:
• 當你希望爲 MongoDB 使用 ORM 時使用
• Knex:
• 當你不需要一個完整的 ORM 解決方案，而只是需要一些工具使編寫查詢代碼更容易，可以使用它
• Knex 是一個生成 SQL 的查詢生成器
• 你擁有 Postgres、MSSQL、MySQL、MariaDB、SQLite3、Oracle 或 Amazon Redshift 數據庫
• Objection.js：
• 你希望 ORM 支持 Knex 支持的所有東西，不使用查詢 DSL(因此你編寫的代碼更接近原始 SQL)，具有基於 Promise 的 API 和良好的文檔

Process management (進程管理)

這個網址提供了部分進程管理器的橫向比較http://strong-pm.io/compare/。注意:它們還包括了 StrongLoop Process Manager，這是一個不錯的工具，但是有點笨重。我建議你在決定使用 StrongLoop 之前先查看一下解決方案。

• PM2:
• 當你希望進程管理器在服務崩潰時處理重新啓動，並允許你控制集羣時使用
• 注意:PM2 所依據的 AGPL 許可證存在一些潛在的違規行爲。這裏有一些討論。我的看法是它最有可能被使用。
• forever:
• 當你需要進程管理器來處理在服務崩潰時重新啓動服務時使用
• 你的部署規模較小(pm2 及其集羣支持用於更大規模的部署)。如果你只有少量的服務/進程，那麼你可能可以使用它
• nodemon:
• 當你希望監視應用程序中的任何代碼更改時使用，並在本地開發時自動重啓服務器
• 非常適合用於開發!

Web Sockets

對於 Web Sockets，我只是推薦 primus，而不是列出一個列表。它支持所有主要的 Web Sockets 實現，並且維護者十分積極。如果你需要換成其他的庫，你可以通過一行代碼更改輕鬆地更換。

• Primus:
• 當你需要 Web Sockets 但又不想被束縛在特定的 Web Sockets 實現時使用

API documentation (API 文檔)

• Swagger-node:
• 當你需要記錄 REST API 並能夠針對端點測試請求時使用

Utilities/misc (通用工具/雜項)

• Lodash:
• 當你需要 JS 實用程序庫時使用
• 你使用了大量的 OOP(面向對象編程)
• Ramda:
• 當你希望使用函數式的編程風格時，請使用
• 你想要像 lodash 這樣的東西，但是在函數式編程範式中
• Moment:
• 在需要解析、驗證、操作和顯示日期/時間時使用
• UUID:
• 當你需要隨機的、唯一的、難以破解的 id 時使用
• NVM:
• 當你希望能夠在環境中安裝的多個 Node 版本之間切換時使用
• Fs-extra:
• 當你需要能夠遞歸地使用mkdir、rm -rf和 Node 中缺少的其他文件系統級功能時，請使用
• Nodemailer:
• 當你需要從 Node 發送電子郵件時使用
• Dotenv：
• 當你需要將.env 文件中的環境變量加載到 process.env 時使用

CLI (命令行界面)

• Commander:
• 當你要構建一個 CLI 程序時使用，該程序將所有參數作爲命令行上的標誌
• Inquirer:
• 當你想要構建一個按順序獲取選項的“交互式”CLI 程序時使用（類似於運行 npm init 時的方式，它會詢問您生成 package.json 文件的一系列問題）

Logging (日誌)

• Winston:
• 當你需要一個日誌庫並需要不同的日誌輸出格式時使用
• Bunyan:
• 當你需要一個日誌庫，並以 JSON 作爲唯一日誌輸出格式時使用
• 你希望爲不同的組件、請求或函數使用不同的日誌記錄器(也就是說，這些日誌記錄器可能以不同的方式解析事件)
• Morgan:
• 當你使用 Express 並且想要記錄 HTTP 請求時使用
• 注意：這將與 Winston 或 Bunyan 一起使用。由於它是中間件，它知道如何處理請求並記錄它，但不處理 Winston 和 Bunyan 所做的日誌輸出的傳輸。

Templating (前端模板)

• Pug (原 Jade):
• 當你需要服務器端模板引擎時，請使用該引擎，該引擎易於閱讀，並且支持開箱即用的子組件代碼塊
• 你只需要輸出 HTML
• EJS：
• 當你需要一個服務器端模板引擎，該引擎完全使用 JS，並且允許空格縮進(Pug 不允許)
• 注意:不支持異步 JS 函數

Testing (測試)

• Mocha:
• 在需要編寫和運行單元測試時使用
• Chai:
• 當你需要證明你的單元測試中的斷言時,請使用
• 注意:這將與 Mocha 一起使用
• Chai-as-promised:
• 當你希望在 promises 上證明你的斷言時，而不是將斷言放在 then 或 catch 中使用
• Sinon:
• 當你需要用於測試的 mock 庫時使用

Tooling (開發工具)

• ESdoc:
• 當你想從你的代碼中生成 API 文檔，並且你正在使用最新的 JS 版本時，請使用
• 默認情況下支持當前版本的 JS(支持 class)，因此如果在代碼中使用 prototypes，請使用 JSdoc
• JSdoc:
• 當你需要支持 ES6 的代碼 API 文檔生成器時使用
• 支持classes 和 prototypes
• ESlint:
• 當你需要一個 linter 來自動查找(和修復)代碼中的語法和代碼格式問題時使用

Debugging (調試)

現在，原生 Node 調試現在已經夠用了，我的建議是直接使用它。幾年前，引入一些 npm 模塊是很有幫助的，而且你可能有一個特定的用例需要一個 npm 模塊，但是現在已經有了足夠的本地支持，如果你對調試沒有任何太瘋狂要求，請務必忽略掉額外的依賴項。

結論

挑選模塊可能很難，但你只需要一些方法點來解決它。當你正在爲如何抉擇浪費時間，或者甚至不知道從哪裏開始時，請使用本指南來幫助你。希望能對你有所幫助