TLDR：

作者爬取了 www.npmjs.com 上所有公開倉庫的資料。從這些資料中分析了過去一年下載量最大的npm包排名；常見前端框架熱、構建工具下載熱度對比；以及各種常見框架的生態現狀。這些資料幫助我們瞭解Npm現有生態，也幫助我們進行前端技術選型。

NPM這個東西大家每天都在使用。

我們每天都在考慮使用哪個包，不使用哪個包。

我們回想一下，以前做出這些決策的依據，無非是：

1. 我以前用過這個包，好用；
2. 開發者社群裡大家都寫文章安利這個包，大家都在用，肯定沒錯；
3. 我隨便在Google/npmjs.com裡搜尋關鍵詞，彈出的第一個就是，看起來文件齊全，而且Star數量也不少，下載量也還行，所以我決定使用這個包。

但是我們從來沒有從統計的層面去獲取資料，然後做決策。從我的眼裡，這是有失偏頗的。

我們從來沒有量化地去做包的下載決策。

這個包每個月下載量有10，算多嗎？

這個包每個月下載有10w，算多嗎？

我們在npmjs面前，始終是一葉障目。

所以我決定對npmjs.com進行資料爬取並統計。希望從上帝的角度，去看npm包的生態現狀。

所以，NPM包的作者們都在關注什麼問題？

我通過獲取NPM包中的Keyword進行詞頻統計，並畫出詞雲，獲得了以下的詞雲圖：

在詞雲中，React的出現次數最高，達到了66w次。出現，另外，Plugin、Component、Node、API、JavaScript、Angular、Generator、CSS、Cordova、Cli、Vue 等都是非常高頻的詞彙。

這其實可以看出前端工程師日常在幹什麼了。天天用React寫Component，天天在Node上寫API，天天寫JavaScript……

這些也是目前前端社群討論最為火熱的話題。

那麼從整體上看，整個npm包的生態如何呢？

我對資料做了整理，根據下載量做了月份的篩選，因為爬取的時間跨度一週，所以直接去除了爬取資料的當前月份與最後一個月份。

畫出瞭如下圖表：

從整體情況來看，今年10月份，下載總量為293億。這是一個很可怕的數字，平均下來，每秒鐘就有100多個npm包被下載。在去年11月，這個數字為81億左右。在房價漲工資不漲的年代，很少數字這麼好看了，至少整個NPM的生態，是非常繁榮而且在發展的。

所以，到底哪個NPM包最受歡迎？

我根據下載量做了統計，結果如下：

事實上，NPMJS上年下載量最大的包，是debug，是九億多次。用處很簡單，是打log。

下載量第二的包，是Debug的好兄弟，supports-color，他的用處很簡單，檢查終端是否支援彩色顯示。

我以前以為我喜歡五彩繽紛的log的顏色，是我比較奇葩。

現在看來，大家都喜歡五彩繽紛的顏色……

第三個是readable-stream，功能大概是Node流的實現，因為在早期版本中Node的流寫得很爛，所以使用這個包來避免Node環境不同的差異。下載量如此大的原因，我想是被babel全家桶dependencies的緣故。

第四個是source-map大家都耳熟能詳了，幾乎我們所有的專案都在使用source-map。

第五個是kind-of，主要用來解決到底例項屬不屬於某一個類的問題。大家寫程式的時候肯定遇到我想知道這個例項到底屬不屬於這個類的哲學問題，解決辦法無非是使用kind-of，或者自己造一個kind-of的輪子。

剩下的譬如glob，qs，async，等等等等，其實都是寫程式的工具包，我們寫一個程式，幾乎以上的東西都是必須的，或者說我們所依賴的包已經集成了這些東西，所以這也是以上的包如此熱門的原因，因為這些包解決了所有前端工程師都會遇到的問題，並且解決得很好。被很多熱門的包所引用，因而下載量非常大。

但其實從Github上來看，這些包並不會是Star非常多的包，debug的Star數量是7k，其實還好，但supports-color就只有可憐的138 Star，readable-stream也只有971 Star，相對於它們在npmjs上的受歡迎程度，這個數字少得可憐。

在這個報告的後面，我們會發現更多的高下載量少Star，或者是高Star但是下載量很少的現象。

高下載量意味著更多的專案在實際情況下使用這個包，高Star意味著這個專案受更多人關注。

但是多人用的包，不一定很多人關注；很多人關注的包，也不一定就很多人用……

在總下載量的排行裡裡，我們並沒有看到任何眼熟的前端框架、後端框架、構建工具的樣子。那麼，這些包究竟生態如何呢？

很早大家就都在說React、Angular、Vue三分前端框架的天下。

那麼，根據下載量來看，三者的關係React、Angular、Vue到底是怎麼樣的呢？

React佔據了超過70%的下載量，Vue以12%的下載量次之，Angular的份額只有10%。

可以看到，React的受歡迎程度，一直是凌駕於Angular和Vue之上的。

前陣子Vue剛慶祝Github上的Star數量剛剛超過React，但是從這裡來看，Vue還有很長一段的路要走。

至於Angular，可能在框架剛出來的時候還有一些優勢，但是可以看到，Vue的受歡迎程度也已經彎道超車了。

反正在React的面前，Vue和Angular都是弟弟。

我們來進一步看React的生態

我以總下載量為主要緯度衡量，篩選Keywords中帶有React字樣的模組，過濾掉基礎工具類包，篩選出最靠前的20個Package。

第一個是prop-types，大家都很熟悉了，下一個。

第二個是hoist-non-react-static，這個用於解決包裝高階React元件的時候，元件包裝後獲取不到包裝前的靜態函式的問題。

第三個是react-dom，很熟悉的朋友了，也不講了。

第四個是warning，是react和react生態的其他元件經常使用的一個東西，譬如說你map一個東西的時候沒有key，瀏覽器提示你的時候，用的就是這個warning。

第四個是warning，是react和react生態的其他元件經常使用的一個東西，譬如說你map一個東西的時候沒有key，瀏覽器提示你的時候，用的就是這個warning。

第五個是ESLint-plugin-React，是專門用於React的Eslint工具。

這裡大家應該看到了很多老朋友了，譬如說classnames、react-redux、react-router、react-transition-group等等。

話說幾年前，react-motion剛出來的時候，大家都說 RIP react-transition-group，但是資料狠狠打臉啊，react-transition-group的下載量遠超react-motion。究竟是react-motion學習成本太高，還是react-transition-group官方背書太厲害？

React全家桶不是吹的。

我們看Vue的生態

此處的篩選方法包括了Description包含Vue的包，並沒有做工具類的篩選。

Vue在Angular和React之後集眾家之長成長，吸納了雙方的優勢並形成了自己的特色。

雖然說下載量並不如React大，但是Vue的優勢也是很明顯的，其中一個很明顯的地方就是學習成本很低，針對國內開發者來講，原生的中文文件讓大家都很舒服。

另外，從上述表中，大家看到的基本都是工具相關的包。

為什麼？

因為像以上的vue-template-compiler、vue-style-loader、vue-hot-reload-api等等都是vue-loader所依賴的東西，然後vue-cli又依賴了vue-loader，所以開發者一旦用上vue全家桶，那麼上述的包下載量就會連環增加。開發者再按需加加點Lint工具，視專案資料流的複雜度上個vuex、如果是中後臺產物就上個element-ui，完事。

其實Vue這種思路很不錯，對於於入門的程式設計師來講，不用跳入babel、webpack配置的深坑，對於老司機來說，新專案也能更快進入開發狀態。

Angular生態就不講了，因為我不怎麼熟悉。

好，來到我們的下一個問題：WEB後端框架哪家強？

我拉取了比較主流的KOA、Express，Sails以及同構渲染那一波火起來的Next.js框架、國外比較流行的Meteor.js進行對比。

這個對比的結果有點震撼人心。

Express穩坐Node後端框架一哥無人能撼動。

Koa對於Express的優勢，是無回撥地獄，更少的繫結，更多的可定製化功能。

但是這個優勢開發者們真的買賬嗎？

首先是回撥地獄問題，express也有類似於@awaitjs/express這樣的async解決方案。其實也不是非koa不可。 更少的繫結，難道Express就很多嗎.

我們可以看一眼Koa相關生態的下載量

大家裝完了koa後都喜歡裝koa-compose、koa-router、koa-bodyparser、koa-static，koa，那和Express有什麼區別呢？

那我還不如直接裝express好了，一步到位。

也許我們在建站的時候，確實應該更多地考慮使用Express，畢竟下載量的生態擺在那，相關的middleware支援也會更為豐富。而想要進行Web框架進行二次開發的時候，可以考慮基於Koa進行二級開發（譬如egg.js、midway等等～）。

我們再來看Express生態的相關的模組

第一的是path-to-regexp，是整合在Express的一個路由工具。

第二個是代理轉發的工具，用於browser-sync等工具，基於http-proxy的一個包裝的元件。

第三個morgan是打log用的，沒錯，他的dependencies裡面有debug。

第四個是killabe ，這個是用來清空所有socket的工具，為什麼這個下載量這麼高，是因為webpack的server用的是他；webpack的server用的是express嗎，不是，用的是koa，但是為什麼會在這裡出現？因為他的keyword裡有express。

後面的也有很多熟悉的包啦，譬如webpack-hot-middleware、cors、multer、passport、csurf、helmet、x-ss-protection、hsts等等。

到底目前主流構建工具下載量哪個多？

我拖取了rollup、parcel、Grunt、Gulp、Webpack等構建打包工具的下載量統計。

首先最慘的是parcel，下載量幾乎成為一條直線，這和它在github上有2w多個star差距有點大，可能大家都只是關注，但並沒有太多人真正把parcel放到自己的專案中去使用。

在過去的半年裡，使用者使用量已經有了指數級的上升了。Parcel已經很努力了好嗎？沒有對比就沒有傷害。

再上面是rollup，一般來說我們用來打包library的時候使用，而打包web app的時候，我們使用webpack。

再上就是grunt和gulp，taskrunner，但是熱度還是webpack比較高，也許和React、Vue框架流行程度有關係，老的專案在用Grunt/Gulp，新的專案基本只用Webpack了。

接下來我們Take a look inside Webpack

由於Webpack的Loader和Plugins都有對應的pattern，所有的loader都以-loader結尾，所有的Plugin都以-plugin結尾，那麼篩選起來就方便了，結果如下：

首先我們看到的是uglifyjs-webpack-plugin，大家用webpack的基礎配置基本都是程式碼壓縮，這個沒毛病。

第二個是style-loader，非常常用的loader，主要功能是在HTML中注入<style>標籤，一般配合第三的css-loader使用，css-loader分析檔案中的import/require，然後對其進行處理。

第五個是file-loader，反正我們有什麼資原始檔，不知道用什麼loader，用它就對了。

後面也有很多熟悉的身影，譬如babel-loader，postcss-loader，url-loader，sass-loader、eslint-loader等等，都是老相識了。

好了，至此，這篇報告從整體、前端、後端、構建工具的角度分別講述了npm生態的現狀。

希望這篇文章能給大家對於npm包有一個量化的認識，也能夠幫助大家進行技術選型。

本文及本文所爬取的資料僅用於學習交流使用。

注：

1. React生態圖中去除的包有：interpret、rechoir、exenv、recompose。