折騰
從 2015 到現(xiàn)在，短短的三年內(nèi)，幾乎每年折騰一下工作流的 “ 更新?lián)Q代 ”。從最早開始使用 Grunt 到 Gulp 再到 Webpack，再到 Rollup，再到 Webpack@2.x ......
在這個前端工具變化如此之快的浪潮里，在前端團(tuán)隊中，并發(fā)合作開發(fā)多個項目，前后端分離等等情況下，配置 或者 升級 或者 遷移 這樣的工作流 基本生產(chǎn)工具，往往造成耗費的就不是僅僅一個人的時間成本，而是十人，數(shù)十人的量級。
所以 一個靠譜、穩(wěn)定、有效的工作流方案就顯得特別重要。
Gulp
14 年 15 年初，因為構(gòu)建性能等問題，已經(jīng)從 Grunt 遷移到 Gulp 了 （ duowan/generator-lego ）。從開源的 Github 倉庫上不難看出，主要 工作流 是基于命令行的形式，配合 yeoman 腳手架工具，以 Gulp 任務(wù)為核心的。
對于 Gulp 定義，官方的說法是
gulp is a toolkit for automating painful or time-consuming tasks in your development workflow, so you can stop messing around and build something.
表明著，Gulp 是一個專門幫你處理一些痛苦耗時的自動化任務(wù)工具。
在這個表述中，Gulp 傾向的是于對 “任務(wù)” 這個概念的處理，而這個 “任務(wù)”，其實如果我們都嘗試配置過 Gulp 的話，也就大概明白是怎樣的一回事。
在這段時間期間，團(tuán)隊面向的業(yè)務(wù)，主要分類占比最大的是 專題類，運營類。
在這類專題基本入口都是從 HTML 開始，寫 HTML Dom 結(jié)構(gòu)，寫樣式，再后可能就寫一些 JS 動效或者 AJAX 。幾乎 JS 占比分量是超級少的，個別頁甚至沒有腳本，單純給到 HTML & CSS 給到后端同事直出數(shù)據(jù)。
那時候 Gulp 所配置的任務(wù)
- 監(jiān)聽匹配文件的變化自動刷新瀏覽器
- 自動編譯 SASS
- 自動補全 CSS3 前綴
- 多雪碧圖合并、2x、3x 拼圖
- 等等
基于編譯 HTML / SASS / 圖片的任務(wù)，已經(jīng)是完全滿足我們的需求了。
Webpack
在 15 年末開始，漸漸接入的業(yè)務(wù)方向改變，需要接觸到 Vue，也就漸漸發(fā)現(xiàn) Gulp 對于 JS 模塊處理的局限性。也在這時候，開始衡量是否需要遷移到 Webpack。
對于 Webpack 定義，官方的說法是
webpack, the production / unbiased / flexible / extensible / open source module bundler.
表明著，Webpack 是一個 xxx 的打包器。
而在這個表述中，Webpack 更多的偏向于資源的整理打包。而這個打包的開始，就是 定義在配置上的 entry。
對于 Vue 或 React 這類型的項目，Webpack 無疑是最最最適合不過了，以 JS 模塊為編寫入口，生成依賴鏈，整理打包出 HTML / JS / CSS / 圖片。
開始本來也就以為 單單工作流核心 將 Gulp 遷移到 Webpack，這樣就可以輕松解決。
直至到后來在 雪碧圖的合并，2x / 3x 多倍圖的輸出上，在 Webpack 上苦苦找尋不了比較完美的解決方案等等。
另外團(tuán)隊還存有一些 專題業(yè)務(wù)類 的需求，也需要兼容舊有項目，團(tuán)隊成員開發(fā)時候，切換前端生產(chǎn)工具的適應(yīng)性等，帶來了一系列的問題。
這時迫切希望有 更加簡便、有效的工作流方案。
Gulp + Webpack
既然 Gulp 對任務(wù)處理的強大，而 Webpack 對 JS 模塊處理的專業(yè)，也就衡量著這兩者的混合。
由 Gulp 基于處理 HTML / SASS / 圖片等部分，Webpack 主要對 JS 模塊進(jìn)行編譯。
帶著這樣的想法，也有網(wǎng)上挺多的思路，例如 gulp + webpack 構(gòu)建多頁面前端項目 。
但是都忽略了較根本上的問題 :
- 每次 JS 改變都重新通過 Webpack 完整打包輸出，效率沒有保證
- Webpack 下 JS 熱刷新應(yīng)該怎么聯(lián)動 Gulp 的熱刷新
基于解決根本痛點的，平衡功能，使用了另外一套方案 :
- Webpack 基于 webpack-dev-server 啟動熱刷新 服務(wù) A
- browser-sync 使用 proxy 代理 服務(wù) A 啟動 服務(wù) B
- Gulp watch HTML / SASS / 圖片 變動
- Gulp watch 變動后觸發(fā) browser-sync reload
- 通過 webpack-dev-server 熱刷新等方式，優(yōu)化 開發(fā)中 JS 構(gòu)建效率
- 通過 proxy 代理 讓 webpack-dev-server 熱刷新同步刷新 瀏覽器
Gulp 負(fù)責(zé)部分的 HTML / SASS / 圖片等任務(wù)基本沒有太大的變動，因而可以兼容到過往的舊項目需求，另外團(tuán)隊成員額外需要了解的是 JS 模塊 Webpack 部分的構(gòu)建，學(xué)習(xí)成本相對降低，在 2015 年末正式作為工作流解決方案加入在團(tuán)隊腳手架工具。
走多一步
2016 年初開始，因組內(nèi)成員的增加，或者工作流功能版本的更新， 都伴隨著維護(hù)工作流的各種問題 ( 即便寫了不能再詳細(xì)的文檔 )，大致回歸到 Node 版本的兼容性，node_modules 的版本功能兼容，Windows / macOS 帶來的兼容性等等問題。
這時在思考著，能否有包裝多一層去讓這些兼容性問題都 避免開呢 ？
其實對于這樣的整體封裝，無疑有兩條路可以走
- 類似于 NW 那樣構(gòu)建出 平臺應(yīng)用
- 類似于 PKG 那樣構(gòu)建出 執(zhí)行程序
在尋找解決方案的時候，發(fā)現(xiàn)了 weixin/WeFlow ，但深入發(fā)現(xiàn) WeFlow 僅基于 Gulp 任務(wù)，功能遠(yuǎn)遠(yuǎn)滿足不了需求。
于是便開始了輪子的重構(gòu)，首先遇到問題是 node-sass 的編譯依賴問題，感謝 WeFlow 開發(fā)者分享踩過的坑（ node-sass 依賴環(huán)境問題 · Issue ），如果團(tuán)隊是使用 less 或者 stylus 都無需重置那些依賴。
另外遇到了最麻煩的問題就是把 webpack 生態(tài) 遷移到應(yīng)用上去，babel 依賴 / vue-loader 依賴 / ..... 其中遇到過各種依賴被重置到全局的問題，都在 babel 或者 vue-loader 的源碼上進(jìn)行 切面置換依賴。
經(jīng)過幾個內(nèi)測版本的開發(fā)下，造出了 legoflow/legoflow
組內(nèi)推行使用后也得到了 贊同的反饋，經(jīng)過了幾個大項目的洗禮后，從功能性變得更加豐富，兼容性上更加穩(wěn)定。
而在今年 6 月也對外兼容版本 LegoFlow
走得更遠(yuǎn)
現(xiàn)在工作流中內(nèi)置的 Webpack 還是基于 1.x 版本，其實在年初的時候是有想法把 整個 Webpack 生態(tài)升級為 2.x，因為在 webpack 2.x RC 期間，對 Rollup tree-shaking 已經(jīng)很垂涎了。
但是 Webpack 正式到 2.x，卻發(fā)現(xiàn)無法兼容到 IE8 ( webpack2 doesn't support IE8 · Issue #3070 · webpack/webpack )，部分業(yè)務(wù)也脫離不了 IE8 的行列。
但計劃在更遠(yuǎn)一點的時間下，看看如何能否到實現(xiàn) Webpack 1.x & 2.x 的無縫切換。
最后
前端團(tuán)隊幾次的生產(chǎn)力工作流工具的遷移，只是前端這個大浪潮中最小最小的 縮影。
每次改變像是意味著 進(jìn)化，在如今 這個前端浮躁的年代，希望 做著相同事情的我們 有著一如既往的 初心 上下求索。
