初探Parcel

昨天趁有點時間看了前不久很火的構建工具Parcel，這裏說下初步使用的感覺，尤爲是將其放到實際項目中和Webpack進行比較。

 

1、前言

首先說下筆者目前的技術棧。最近的前端項目主要以管理後臺爲主，技術棧都是React.js + Redux + React-Router + Antd + Create-react-app這套，版本均爲較新的版本。Webpack構建工具體系由Create-react-app腳手架初始化，因默認打包功能不太豐富，筆者eject出打包相關的配置文件，在原基礎上添加了額外功能：

1. 代碼分割與模塊異步懶加載

2. 模塊按需加載

3. less以及postcss的支持

4. 字體文件的打包

5. JS模塊熱替換(原始只支持樣式的熱替換)

6. dev-server(Express)正向代理、代理的destination參數接收、HTTPS的啓用以支持h/2協議

前5項考慮到資源大小、首屏性能、樣式的兼容以及書寫的方便、總體開發的便捷性，是不管在dev或是production環境都會有的。

第6項正向代理是由於筆者這個項目的底層是分佈式文件存儲系統 + 基於Cluster模塊的Node.js集羣 + MongDB分片式集羣 + HA集羣，dev環境是跑在Vagrant Centos7.x虛擬機集羣裏的，production環境是直接跑在Centos7裏的，對操做系統以及機器硬件依賴大。數據流從文件存儲系統底層傳遞到Node.js層再傳遞到Web前端，且Web前端和Node.js後端只有基於HTTP、Websocket的交互，在開發時出於工程化的考慮，直接和底層環境隔離，進而方便調試，無需到Vagrant起的虛擬機中部署修改後的前端代碼，也無需Fiddler或者Charles代理服務端的文件到本地文件，或是依賴Jekins持續集成。只須要Webpack的dev-server代理到Node.js上層Nginx便可，在'npm start'後跟上協議 + 跑有Node.js服務的IP + Node.js進程監聽的端口號便可，會將此參數傳給dev-server的正向代理配置。

因而可知，若是說你的項目很簡單，CLI提供的初始功能便可知足需求，正是如此Facebook在Create-react-app中，直接把最基本的構建有關的文件都放到了node_modules中，只暴露出了命令，使用者根本不須要去維護構建有關的文件。若是說業務需求較複雜會對工程化要求高，若是CLI工具初始化的Webpack打包體系的初始功能不知足業務需求，也是須要額外加入不少東西的，而且須要咱們手動去配置。

Webpack的功能確實強大，相對於Browserify來講，Webpack真的是大而全。但相似於字典的API文檔和各類loader與plugin運用，無形中提升了整個工具鏈的技術門檻，對於大多數沒有深刻研究的開發者來講，只能是知道Webpack的基本用法和要點的概念，再用到具體的loader和plugin的時候再去查看文檔，而後過必定時間不使用基本又會忘掉。對於初學者來講而要準確的說出某個loader或者plugin的功能和配置方法是有必定難度的。並且Webpack的每一個大版本之間也存在必定的功能和API上的變化，當你熟悉了這個版本後，下一個版本就來了...... 有沒有一種"鐵杵磨成針"的感受呢？

目前前端的開發模式、技術棧與工具鏈基本都相同，爲何不能在構建工具內部就給出能適配大多數業務需求的默認的配置而省去煩人的手動配置呢？因此Parcel號稱的零配置的吸引力是很大的。

 

2、Parcel初探

筆者新起了一個demo項目，但功能複雜度模擬真實項目：

按照Parcel官方要求作了最基礎的package.json和.babelrc配置，其餘都應用零配置默認的項，不作額外配置。Parcel版本爲1.9.3.

index.html爲Parcel打包的入口，依賴src/index.js文件。

src文件夾爲源資源目錄：

src --
       |--  components      存放高度抽象的公用組件

　　 |--  redux      存放redux初始化、action、reducer

       |--  styleSheets      存放公共和各組件的樣式less

       |--  views      存放業務視圖組件

       |--  index.js      JS入口文件

路由、代碼分割、Antd UI組件按需加載、Redux相關、樣式等功能都支持。這是使用Parcel打包過程：

 

打包後的結果：

這是打包過程當中對計算機硬件資源的利用：

 用筆記本開發的同窗請注意散熱...

 

3、使用Webpack打包同一個項目

 

筆者再起了一個項目，技術棧和上個段落中的項目相同，但使用前言中提到的Webpack工具鏈打包該項目。懶得修改index.html的目錄，因而新建了public文件夾把index.html放進去，並刪除了<script>引入，由'html-webpack-plugin'插件注入JS腳本依賴。

結果以下：

 

 

這是打包過程當中對計算機硬件資源的利用：

 

4、有區別處的對比

1. 打包速度

首先當前版本Parcel在速度上絕對比Webpack未使用HappyPack時要快上不少，從計算機CPU使用率能夠看出，筆者計算機CPU是i7 4770HQ 4c/8t，在執行Parcel構建時，8個線程均被使用上了，雖然超線程技術產生的額外線程的是引用率並比不上物理核心，但已經很不錯了。第二次使用Parcel打包後，能夠看到速度較上次還有明顯提高，這是由於第一次打包生成了.cache目錄的緣由，能夠記錄上一次打包的狀態。反觀Webpack僅僅只能使用4個物理核心的線程，對核心線程的利用率也並不高，對超線程技術支持不友好，並且耗時很長，拖拖拉拉，固然使用上了HappyPack後會有必定改善。這就是Parcel打包速度快的緣由。

2. 打包質量

在零配置下Parcel彷佛沒有相似於TreeShaking的按需引用技術，而致使打包出來的資源大小要大不少。總所周知，Webpack的TreeShaking可以抖掉引入包中並未真正使用的模塊，可是parcel並無，咱們在disk文件夾下的src.js的下，發現了以下代碼：

筆者只在代碼中引用了Button組件，可是整個Antd UI庫的全部組件都被打包進來了，這個srcjs文件異常龐大。若是說咱們在loadsh的時候，引入了所有loadash，看在它不大的份上還情有可原，可是整個UI庫的引入，致使大小提高到了4Mb，以及和使用Webpack打包出的main.js(200KB)作比較，就難以接受了。

3. 使用場景的支持性

在純的web前端項目中，Parcel彷佛沒有什麼問題和報錯，而當咱們打包Node.js項目時，會產生由於有些require寫法不支持而報錯等問題，固然打包後端醒目可能不是Parcel的目的。而Webpack在這方面作得較好，支持構建的應用較爲豐富得多，基本上使用JS的各類項目都支持。

 

5、經過HappyPack給Webpack打包加速

直接上個代碼例子：

沒有使用的HappyPack的狀況：

使用之後，須要在plugins配置下增長對應的HappyPack實例：

加入HappyPack後，在打包時，CPU使用率較以前高出不少，打包速度有明顯提高。

可是筆者在HappyPack實際使用中還遇到了兩個問題：

1. 對圖片資源的打包，會使圖片資源數據被破壞，致使圖片資源沒法正常使用。這個問題筆者在HappyPack的Github項目Issue裏也看到有人提出過，但並無找到明確的解決辦法。

2. 對extract-text-webpack-plugin支持很差，這個插件堪稱webpack裏面最不穩定的一個插件。

固然以上問題可能和筆者所使用的Webapck有關的loader和plugin自身有關聯。

 

6、總結

Parcel的零配置打包着實讓人眼前一亮，可是限制仍是不少的，而且爲了零配置而拋棄掉了不少靈活配置，致使對打包過程和資源輸出有自定義需求的時候還必須本身去修改或者使用額外的插件。那麼這樣一來豈不是又回到了Webpack等的老路上去了。總之若是沒有太複雜的自定義的構建業務需求、也沒有引用某些重型UI庫，使用Parcel可以讓整個打包過程很清爽，反之請使用Webpack。若是以爲Webpack構建太慢，可使用HappPack增長多進程處理以達到模擬多線程的目的，充分利用計算機CPU超線程技術的功能(若是支持的話)。但HappyPack並不能完美適配全部loader或plugin，這點也不能忽視。固然這也不是必須的，由於又會有誰在不停地打包開發環境的代碼呢？並且通常大型項目，也會直接使用CLI腳手架工具搭建環境，像React.js官方的Create-react-app同樣，構建相關的文件都沒有暴露出來的，提供能夠直接使用的'npm start'、'npm run build'等命令。若是你不須要自定義修改，從某種程度來講腳手架工具就是零配置的。新的Webpack4.0大版本也支持零配置，若是你不須要額外的自定義功能的話。

因此Parcel還需打磨，它還不具有讓開發者放棄現有構建工具的吸引力。