原文:Which of the 635000 npm modules do I choose? - Corey Cleary

原創翻譯，發表於個人博客He Xings waking life

如有謬誤，懇請指正

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

開發者不停的尋求幫助/抱怨：

"對模塊的選擇困難正在蠶食我們"

"X 模塊和 Y 模塊有什麼區別？哪一個更好？"

"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 更「自帶電池」(譯者注:原文"batteries"意為您不必重複造輪子，大多數您需要的功能都能通過（已有）庫完成。您能導入並使用它們。)的框架，但又不像 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 的接受程度。在 2018 年，大多數開發人員應該沒問題了
  • 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 (進程管理)

這個網址提供了部分進程管理器的橫向比較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 來自動查找(和修復)代碼中的語法和代碼格式問題時使用(譯者注:可參考本人博文vscode + vetur + eslint + prettier 實現團隊代碼風格統一)

Debugging (調試)

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

結論

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


推薦閱讀：
相關文章