如何評價0配置的web打包器parcel？

01-06

眾所周知，目前前端開發絕大情況下使用webpack、rollup等打包工具，但是配置太繁複了。
然而今天在Github Trending看到了這個新東西： Parcel，在沒有配置的情況下就能開心的前端打包了。
那麼問題來了，怎麼看待0配置的前端打包工具？它的應用場景和發展前途又會如何？

看到 ParcelJS 還是眼前一亮的。

新建 index.html、index.js 和 index.css，然後 parcel index.html，就能拿到可運行的 html、js 和 css 組合。html 可以作為入口正是我期望的，這讓前端開發回歸到本來的狀態，很舒服。

ParcelJS 是以 assets 方式組織的，assets 可以是任意文件，所以你可以構建任意文件。而在 webpack 中，只有 JS 是一等公民（webpack@4 會增加 CSS 為一等公民），所以必須是以 JS 為入口去組織其他文件，這很彆扭。

速度是 ParcelJS 主要賣點。體驗下來確實快，原因是多核（通過 worker 平行構建）和文件系統緩存（二次構建會快，和 webpack 的 dll 異曲同工）。不過 webpack 也有多核處理 loader 和壓縮的插件，沒對比過，不知道差異如何。另外 webpack 的構建速度慢在 dev 模式下還是可以的，主要還是壓縮慢，在壓縮速度上沒有突破，僅提升編譯速度，只能解決一部分問題。

關於 0 配置。ParcelJS 本身是 0 配置的，但 HTML、JS 和 CSS 分別是通過 posthtml、babel 和 postcss 處理的，所以我們得分別配 .posthtmlrc、.babelrc 和 .postcssrc。

功能上，Code Splitting 和 Hot Module Replacement 沒啥新的，和 webpack 等工具相同。對於我來說，功能目前還缺 SourceMap、公共文件提取、publicPath 配置（Code Splitting 需要）、Tree Shake 和 Scope Hoist 等。

很好的開始，持續維護的話應該不缺用戶。

約定大於配置的新產物

但是對於打包工具來說速度不是最首要的，生態才是。

下面從實踐出發談談我個人對打包工具的理解

曾經

打包工具的出現，很大程度上緩解了傳統的手動引入資源文件(css, js等)到html帶來的不便。從。從最初的require.js模塊載入庫以及相關規範出現開始，社區就開始進行各種嘗試。到gulp利用pipe以及watch概念來構建前端自動化流程，之後引入了browserify打包作為構建工具中的一環，最終到了現在webpack集大成者。

webpack當年首先是作為一款與browserify功能相當的打包工具/庫，出現在社區中的。所以你會常常看見社區里的教程/問答貼: gulp + webpack 或是 gulp + browserify。當然還有但是風韻猶存的grunt，以上組合可以自行想像。

之後webpack重點開發了自身作為一個構建工具的作用，而不是僅僅作為一個打包庫寄人籬下。在這之前，我們都沒見過打包工具需要去監聽文件變動而觸發打包動作(例子一個)，他們都只是從gulp/grunt這種構建工具的pipe來獲取到具體變化，再去執行打包動作。所以一句話，像監聽變化、assets資源優化等等這種事情，在以往打包工具/庫是觸及不到的。打包工具只針對js作為入口文件，遞歸獲取依賴，建立依賴樹，逐個利用自帶的或第三方的中間件來最終輸出bundle js。

當下

剛剛提到webpack不滿足於自己僅僅只是一介打包工具而存活於世，或是說社區本意就是將它打造成為一款前端項目構建工具。webpack推出了一系列的功能，漸漸發覺，gulp能做的事情，現在webpack都能做到了，甚至還多了一系列的gulp配合打包庫才能做到的功能。Parcel無配置，從assets出發的構建工具，嶄露頭角。

我超喜歡在webpack的個個loader、plugin都是人才說話又好聽

未來

未來肯定是屬於操作簡單便捷的構建工具的，它要能支持js、html、css三劍客的打包，速度足夠快，生態夠好。但是依然要有定製性：

一半是傳統多頁面應用，一半是SPA的業務場景。
添加各種稀奇古怪的js語言。
針對css進行優化，像js那樣能夠提取出common chunk。webpack 4添加了許多特性對css打包進行了支持。我們拭目以待。
針對業務進行分組打包，而不是所有的entry都要強制打包（目前可以利用多config特性來解決，但是要小心webpack-dev-server的坑）。

思考：針對場景的配置成本

如果你要使用react，就用create-react-app，如果你要使用angular，就用angular-cli。

但是如果你不用前端框架，或者嫌這些cli太重了，或不透明（其實不然），當然可以用parcel。

但是如果你又要引入typescript或者一些其他神奇的plugin到parcel中，那麼又成了鐵頭娃、填坑俠。

試了一下，寫了幾個例子 justjavac/parcel-example

速度是最大的賣點。

我用的 Win10 系統，說幾個踩到的坑吧

編譯期不能報告錯誤

我的代碼沒有導入 React 包，編譯時沒有錯誤，運行時報錯。畢竟是基於 assets 的打包工具。

已經有人提到了，並行構建

但是在 git bash 的 MINGW 中無法正常關閉，Ctrl + C 之後再次運行時，出錯

在 PowerShell 中沒有問題。

說一個上面答案沒有提及的點。

Webpack 之所以有時感覺很慢，是因為代碼轉譯全靠 loader 進行字元串處理。比如一個 index.js 有可能要經歷 loaderA -&> loaderB -&> loaderC，這些 loader 完全不知道彼此之間的存在，都是接過來一個字元串自己處理，然後再交給下一個。如果最後再 uglify 一下還要先 parse 為 AST（抽象語法樹）再壓縮，這一步也是比較耗時的。用簡單公式可以理解為（n 為需要 transform 的過程）：

Webpack 打包時間 = parse string * n + transform * n + parse to AST + compress

在 parcel 代碼轉譯是先 parse 為 AST，然後再進行 transform。即便有多步轉譯流程，最後再加上 uglify，全部也只用 parse 一遍。用簡單公式可以理解為（n 為需要 transform 的過程）：

parcel 打包時間 = parse to AST + transform * n + compress

因此，parcel 至少為我們提供了一個很好的思路：多步轉譯 + 壓縮時，每一步都可以利用到已經解析過後的 AST，只要完成各自的 transform 即可。

其他 parcel 中的特性像是多進程、緩存等，其實都可以利用 Webpack 的一些相關模塊搞定（Happypack、DllPlugin 等），但單從代碼轉譯這一點上來說確實比 Webpack 要先進。

應該能從webpack下搶到許多肉，就像rollup那樣，但項目中還是需要各種處理，只有像webpack 那樣豐富的生態圈才能滿足大家層出不窮的奇葩需求

parceljs 是 fis3 的改進版，將 webpack 的優點融合進了 fis3，再優化下了使用體驗。

parceljs 說自己是0配置有點誇張，0配置的東西是不可能做到廣範圍使用的。如果處理簡單的項目 webpack 其實也接近於0配置。

webpack 最大的優點其實在於它龐大的社區，parceljs 也提供了 Packagers 和 Plugins 機制，但這需要時間的積累。

目前看來parceljs無法勝任項目的需要。

webpack 以 js為入口，parceljs以html為入口，這方面我更贊成webpack，因為 js 運用範圍越來越廣。

以上：我覺得 parceljs 的前景不會很好。

General purpose 的0配置打包器是不存在的。

你0配置幫我編譯efml模板試試～（逃

正經說：

0配置的情況適用於大多數快速出demo的場景，可以做到這一點的有很多工具。結合unpkg啊jsdeliver啊之類的CDN以及jsfiddle和jsbin這樣的網站甚至在瀏覽器內就可以完成demo編寫。需求量稍微大一些的比如需要自定義特定格式的模板、特定二進位文件之類的東西時0配置是不可能實現的。雖說可以通過特定包名來自動引入插件，其實「添加插件」這個過程已經可以算是配置的一部分了。又比如我不想用babel，parcel又不允許我改成buble，這就比較尷尬了。

倒是這兩天比較熱門的 https://medium.com/@ericsimons/introducing-turbo-5x-faster-than-yarn-npm-and-runs-natively-in-browser-cc2c39715403 可以一看，暫未開源，不過值得期待一下。

看了問題描述挺激動，一搜沒搜到，點了題主的鏈接過去一看，……

怎麼說呢，其實我並不贊同以 import 或 require 為關鍵字的打包方案。打包就是打包，模塊就是模塊，文件切割與模塊解耦其實不是一個層面的事情，混在一起其實並不好。

import 或 require 其實書寫的是懶載入以及解耦、緩存、重用（甚至獨立為第三方庫級重用）邏輯。而打包很多時候則是把一個文件寫不下的單個模塊組裝起來。將模塊引入關鍵字作為文件引入關鍵字使用，智能很容易變成智障。

至於 html、css 的進一步索引打包，在前端組件化的背景下，除了沒有必要，還有些添亂（@import ""、url("")、src=""等，理由同上）。我覺得 js 的打包工具和其它文件的打包工具其實沒有必要混在一起，js 文件的打包工具只要能單層載入其它類型文件就行了。

過一陣子我會把我寫的一個打包工具開源出來，希望能對需要的人有所幫助。

——

https://github.com/LongTengDao/j-pack

喏。。就這個

賀老師預測準確，果然出現了！

不管三七二三一先at一下賀老師

至少賀老短期內不用動手親自做了

@賀師俊

官網給的例子運行了下就是一個windows bug，看來又是一個軟黑^O^

Zero configuration的只是個噱頭，宣傳意義大於實用意義。只能說是 less configuration，畢竟你還得配置 Babel，PostCSS，PostHTML 不是么？

抖個機靈，讓別人幫你配置好開發環境對你來說也是0配置。

就看你怎麼理解0配置了。目前來講如果0配置就是針對特定應用場景的開箱即用，像create-react-app，angular-cli這些工具都可以實現0配置。前提是你得按他們的規矩來。

根據開放封閉原則，如果你要實現各種個性化的需求，0配置不可能，肯定得留出各種擴展介面，這時候肯定要寫配置文件。

目前這個工具其實就是幫你配置好了一般情況下的打包問題，解決了一些場景下的痛點。目前，像ts支持，代理等等都還不支持，看看 issue 里的 feature request 就知道了，有些功能作者為了0配置，直接就不管了。如果說所有情況他都要支持，呵呵，玩脫是遲早的。

總的來說像 webpack 這樣的打包工具還是首選。自己配不來？讓別人給你配一個啊！

一直在等這種零配置（少配置）的構建工具，一周時間star數暴增6k多的事實證明不少人都喜歡更簡單一點的工具。webpack實在是看著就頭疼，你作為一個構建工具，連最基本的js.css這些都要配插件才能用，真的好嗎？不管parcel未來如何，至少讓大家知道webpack這種重配置的不是唯一的選擇，競爭能促進大家都變得更好

這幾天用了一下說下感受.

我覺得這個打包器最大的賣點還是0配置.

1.所謂的快是建立在webpack沒有開啟多核打包和文件緩存的前提下,當然這些在webpack里是需要開插件由開發者自己去定製的,我相信webpack配置好後雙方速度應該不會差太多.

2. 還有所謂的打包方式,parcel更符合傳統前端以html為入口的方式,我覺得這並不能成為什麼優勢,只是兩個打包器選擇的不同而已,一個打包器好不好應該由可觀的速度、友好的提示、豐富的周邊和高度的可定製化等等來決定，也不是啥啥更符合傳統前端來決定,另外傳統前端要啥打包器,直接開html+css擼就行.

-------------------------------

對比:

前端打包器發展到今天其實很難有什麼技術上翻天覆地的創新,只不過不同的打包器側重的方向不同而已.

webpack更側重js為王,把一切打包成js,提供了高度的可定製化配置,你甚至可以用海量的插件把它拓展成一個前端構建工具(事實上webpack已經被這樣使用了),但是帶來的後果是配置極其繁瑣,上手成本很高,對於大部分前端來說現在能自己配置好webpack就實屬不易了,更別提搞清楚原理再進行拓展開發了.

parcel的優勢就是所謂的0配置(指的是配置少),當然0配置是指相對於webpack他直接將常用的在webpack中需要通過開發者自己配置的功能作為打包器默認的功能,省去了開發者多次重複配置的成本,webpack要做到parcel同樣的效果估計少不了一大堆插件手動拓展.

parcel的方向很好,在webpack愈發複雜繁瑣的情況下我們需要一個更加傻瓜化的打包工具,不同的情況選擇不同的打包器不是挺好嗎?當然parcel的生態還不夠健全,但是就這幾天時間star瘋漲到小6000的速度,我覺得parcel前景不會太差.

ps:大家可以讀讀源碼了,這源碼比webpack友好了不知道到哪裡去了.

被吐槽了，更新一下，昨天看了看也嘗試了一下。發現不支持sourcemap.....瞬間就萎了然後我搜了一下issue 提到sourcemap太慢所以暫時也沒支持具體link現在爪機不好補上去然後有人提到了可以借鑒cheap eval方式。嘛，原理具體的還么搞的很清楚，但是目前來看，我肯定不會在正式項目中用的。

0配置的話，約束和限制以及一些潛在需要自定義的配置項都可能存在(尤其是環境和場景限制時)。

樓上有大大回答中也提到了還有一些其它的功能特性需要支持。

嘛我是很看好的(雖然我只是個喳猹

我就想說python社區能不能學學人家JS，一頓飯的功夫就趕不上節奏了

感覺fis也可以做而且還有其他插件使用

試了一下, 速度感覺並沒有那麼快, 配置簡單倒是真的, 如果真正使用的話各種插件缺少將是很大的坑

使用了一下，簡潔和快速是最大的賣點。

不過一上來，官網最簡單的例子都不能運行成功。查了一下，是node版本不是8以上的問題。

自己玩玩可以，真的要在項目中跑還是有點慌的。

工具而已，如果沒有什麼創新性的突破便沒什麼興趣。作為一名前端開發工程師需要整天在工具裡面做出選擇也是蠻累的。

體驗了一把。寫了一篇關於 parcel 的文章。

從 webpack 到全面擁抱 Parcel #1 探索 Parcel