原文:Which of the 635000 npm modules do I choose? - Corey Cleary
原創翻譯,發表於個人博客He Xing's 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 請求)
-
- 當您需要基於回調的 HTTP 請求時可選擇它,例如從一個 REST 服務連接到另一個。
-
- 當您需要基於 Promise的 HTTP 請求時可選擇它
- 注意:您可以使用request-promise,但是 axios 的依賴更少,並且基於原生 Promises
Web frameworks (Web 框架)
-
- 如果您想爲 API、網站或單頁應用程序使用輕量級 web 框架,請使用它
- 您不介意使用回調作爲默認的異步處理方式
- 使用該框架的模塊生態極爲繁榮
- 您需要一個支持和故障排除的大型社區
-
Koa:
- 當您想要一個比 Express 更簡潔的框架時使用
- Koa 更像是一箇中間件層,它不提供模板或開箱即用的路由,因此更適合 API 開發
- 要想支持開箱即用,您需要 async / await
-
- 如果您想要一個比 Express 或 Koa 更“自帶電池”(譯者注:原文"batteries"意爲您不必重複造輪子,大多數您需要的功能都能通過(已有)庫完成。您能導入並使用它們。)的框架,但又不像 Sails 那麼多,那就使用它
-
- 當您需要像 Rails 這樣的東西時,請使用它,它具有幾乎所有功能(但是根據您的應用程序可能不需要那麼多)
Validation (前端驗證)
-
- 在需要驗證 JSON 時使用(比如來自 web 請求)
- 您希望與應用程序的其他非 JS 部分共享這些驗證規則(因爲它是 JSON,所以您可以這樣做)
-
- 在需要驗證輸入時使用,並且喜歡鏈式調用的風格(譯者注:代碼見下方),而不是在 JSON 中定義驗證規則
- 您正在使用 Hapi(Hapi 自帶 Joi)
const schema = joi.object().keys({
id: joi.string().guid().required(),
username: joi.string().alphanum().min(8).required()
});
Authentication (身份認證)
-
- 當您需要爲您的網站或 API 使用身份驗證中間件時使用
- 您希望能夠在多種身份驗證類型(Oauth,Facebook 等)之間進行選擇
- 您需要管理會話
Asynchronous (異步)
-
- 當您需要使用舊版本的 Node,而該版本的 Node 支持只支持回調而不支持 Promises 時
-
ES6 原生 promises (原生 JS, 非 npm):
- 在使用大於 0.12 的 Node 版本時使用
- 另一件需要考慮的事情是您的團隊對 Promises 的接受程度。在 2018 年,大多數開發人員應該沒問題了
-
async / await(原生 JS,非 npm)
- 當您爲了逃脫“回調地獄”卻又誤闖“Promise 地獄”
- 您有很多來自 Promises 的
.then
和.catch
Database (數據庫)
下面是數據庫驅動程序、ORM 和查詢生成器的組合。在使用 ORM 之前,我強烈建議您首先確保需要使用它。當您可以只使用原始 SQL 或查詢生成器時,它們通常會添加另一層抽象,這層抽象不一定能夠提供足夠的回報。
-
- 當您不需要完整的 ORM,而是需要使用原始 SQL 查詢數據庫時使用(這些是驅動程序)
-
- 當您不需要一個完整的 ORM,而是要直接查詢 MongoDB 時使用
-
- 當您希望爲 MongoDB 使用 ORM 時使用
-
Knex:
- 當您不需要一個完整的 ORM 解決方案,而只是需要一些工具使編寫查詢代碼更容易,可以使用它
- Knex 是一個生成 SQL 的查詢生成器
- 您擁有 Postgres、MSSQL、MySQL、MariaDB、SQLite3、Oracle 或 Amazon Redshift 數據庫
-
- 您希望 ORM 支持 Knex 支持的所有東西,不使用查詢 DSL(因此您編寫的代碼更接近原始 SQL),具有基於 Promise 的 API 和良好的文檔
Process management (進程管理)
這個網址提供了部分進程管理器的橫向比較http://strong-pm.io/compare/。注意:它們還包括了 StrongLoop Process Manager,這是一個不錯的工具,但是有點笨重。我建議您在決定使用 StrongLoop 之前先查看一下解決方案。
-
PM2:
- 當您希望進程管理器在服務崩潰時處理重新啓動,並允許您控制集羣時使用
- 注意:PM2 所依據的 AGPL 許可證存在一些潛在的違規行爲。這裏有一些討論。我的看法是它最有可能被使用。但如果您有任何問題,請諮詢您的法律部門,因爲我不是律師。
-
- 當您需要進程管理器來處理在服務崩潰時重新啓動服務時使用
- 您的部署規模較小(pm2 及其集羣支持用於更大規模的部署)。如果您只有少量的服務/進程,那麼您可能可以使用它
-
- 當您希望監視應用程序中的任何代碼更改時使用,並在本地開發時自動重啓服務器
- 非常適合用於開發!
Web Sockets
對於 Web Sockets,我只是推薦 primus,而不是列出一個列表。它支持所有主要的 Web Sockets 實現,並且維護者十分積極。如果您需要換成其他的庫,您可以通過一行代碼更改輕鬆地更換。
-
- 當您需要 Web Sockets 但又不想被束縛在特定的 Web Sockets 實現時使用
API documentation (API 文檔)
-
- 當您需要記錄 REST API 並能夠針對端點測試請求時使用
Utilities/misc (通用工具/雜項)
-
- 當您需要 JS 實用程序庫時使用
- 您使用了大量的 OOP(面向對象編程)
-
- 當您希望使用函數式的編程風格時,請使用
- 您想要像 lodash 這樣的東西,但是在函數式編程範式中
-
- 在需要解析、驗證、操作和顯示日期/時間時使用
-
UUID:
- 當您需要隨機的、唯一的、難以破解的 id 時使用
-
NVM:
- 當您希望能夠在環境中安裝的多個 Node 版本之間切換時使用
-
- 當您需要能夠遞歸地使用
mkdir
、rm -rf
和 Node 中缺少的其他文件系統級功能時,請使用
- 當您需要能夠遞歸地使用
-
- 當您需要從 Node 發送電子郵件時使用
-
- 當您需要將.env 文件中的環境變量加載到 process.env 時使用
CLI (命令行界面)
-
- 當您要構建一個 CLI 程序時使用,該程序將所有參數作爲命令行上的標誌
-
- 當您想要構建一個按順序獲取選項的“交互式”CLI 程序時使用(類似於運行 npm init 時的方式,它會詢問您生成 package.json 文件的一系列問題)
Logging (日誌)
-
- 當您需要一個日誌庫並需要不同的日誌輸出格式時使用
-
- 當您需要一個日誌庫,並以 JSON 作爲唯一日誌輸出格式時使用
- 您希望爲不同的組件、請求或函數使用不同的日誌記錄器(也就是說,這些日誌記錄器可能以不同的方式解析事件)
-
- 當您使用 Express 並且想要記錄 HTTP 請求時使用
- 注意:這將與 Winston 或 Bunyan 一起使用。由於它是中間件,它知道如何處理請求並記錄它,但不處理 Winston 和 Bunyan 所做的日誌輸出的傳輸。
Templating (前端模板)
-
- 當您需要服務器端模板引擎時,請使用該引擎,該引擎易於閱讀,並且支持開箱即用的子組件代碼塊
- 您只需要輸出 HTML
-
EJS:
- 當您需要一個服務器端模板引擎,該引擎完全使用 JS,並且允許空格縮進(Pug 不允許)
- 注意:不支持異步 JS 函數
Testing (測試)
-
- 在需要編寫和運行單元測試時使用
-
Chai:
- 當您需要證明您的單元測試中的斷言時,請使用
- 注意:這將與 Mocha 一起使用
-
- 當您希望在 promises 上證明您的斷言時,而不是將斷言放在 then 或 catch 中使用
-
- 當您需要用於測試的 mock 庫時使用
Tooling (開發工具)
-
- 當您想從您的代碼中生成 API 文檔,並且您正在使用最新的 JS 版本時,請使用
- 默認情況下支持當前版本的 JS(支持 class),因此如果在代碼中使用 prototypes,請使用 JSdoc
-
- 當您需要支持 ES6 的代碼 API 文檔生成器時使用
- 支持
classes
和prototypes
-
- 當您需要一個 linter 來自動查找(和修復)代碼中的語法和代碼格式問題時使用(譯者注:可參考本人博文vscode + vetur + eslint + prettier 實現團隊代碼風格統一)
Debugging (調試)
現在,原生 Node 調試現在已經夠用了,我的建議是直接使用它。幾年前,引入一些 npm 模塊是很有幫助的,而且您可能有一個特定的用例需要一個 npm 模塊,但是現在已經有了足夠的本地支持,如果您對調試沒有任何太瘋狂要求,請務必忽略掉額外的依賴項。
結論
挑選模塊可能很難,但您只需要一些方法點來解決它。當您正在爲如何抉擇浪費時間,或者甚至不知道從哪裏開始時,請使用本指南來幫助您。