不單單是複製粘貼 - 聊聊前端腳手架

許多團隊在制定前端工程方案時會加入腳手架模塊。雖然不一樣的團隊對工程化的理解和實施有所差別，可是對於腳手架的定位基本是一致的：建立項目初始文件。這是一條看起來十分簡單地準則，可是對於這條準則應該如何理解，如何實施卻並非一件很簡單地事情。

在探索這條準則的深度以前，咱們不妨看看相似的一些成熟方案，好比Eclipse。這個大名鼎鼎的IDE軟件被不少Java和Android開發者使用。經過Eclipse建立一個新項目時，它提供了豐富的配置項，這些配置項能夠概括簡化爲如下流程：選擇項目類型 -> 選擇項目目錄 -> 配置項目細節 -> 最終確認 -> 完成。這是腳手架最基本也是必須具有的流程。從這個流程中能夠總結出腳手架的本質：方案的封裝。

由此，咱們明確了腳手架的定義：腳手架做用是建立項目的初始文件，本質是方案的封裝。

固然，腳手架建立項目流程之中還有不少細節，而且前端項目的多樣性和複雜性更加爲腳手架流程的實現增長了難度。這篇文章簡單闡述一下筆者的一些淺見，但願可以給你們一些啓發。

1. 腳手架在前端工程中的角色

1.1 「用完即棄」的腳手架

以前寫過一篇淺析前端工程化，簡單介紹了前端工做流模型，簡化以後能夠用下圖歸納：

腳手架在前端工做流中負責項目起始階段建立初始文件。與其餘功能模塊不一樣的是，腳手架是一個徹底「啓下」的模塊，它沒有任何前置依賴。建立完成項目初始文件以後，腳手架就再無用武之地了。

「用完即棄」的工做模式令腳手架的實現由很大的躍遷性。你能夠用最簡單的複製粘貼就能完成腳手架的工做，而一個完備、成熟的腳手架即便提供了很是豐富的交互配置，最終目的也「只」是建立了一堆初始的項目文件。既然結果同樣，那爲何還要花費時間和人力成品去開發複雜的腳手架方案呢？

躍遷是量子力學術語，意思是狀態發生跳躍式變化的過程。之因此將這個詞用在這裏是由於高度完備的腳手架相比較低級形態的腳手架而言，可以帶來質的飛躍。

這是一個很是現實的問題，互聯網產品迭代的快速節奏下，開發團隊最注重的就是投入產出比，而腳手架的投入產出比「看上去」是最低的。環顧目前前端的工具生態，最多的是構建工具，固然咱們不能否定構建確實是最複雜的功能。而腳手架工具是最少的，前端社區對腳手架的討論也很是稀少。你可能據說過大名鼎鼎的yeoman，可是很難再想出第二個腳手架工具了。

單獨來看，腳手架可能並不具有很高的「性價比」，但若是你的團隊有一套完整的前端工程體系，腳手架的做用就會被放大。前端工程體系的功能涵蓋範圍廣，封裝的方案類型多，對應的配置項也很是複雜。並且，大多數前端工程體系的開發者並非一線的業務開發者。對於業務開發者來講，這套工程體系就是一個黑盒，他們不須要了解其中的複雜原理，只須要知道如何配置便可。因此業務開發者的需求就是快速開發快速配置，而且生成的配置項跟項目要對應，既要知足項目的功能需求，又不能有「混淆視聽」的冗餘功能。

前端工程體系不是Vue、React這種開發框架，工程體系只是一種「服務」，是輔助性質的。學習曲線應該平緩，即便文檔再清晰易懂，也不該該要求業務開發者去花時間學習各類細節。這就是腳手架要解決的切實問題，簡單說就是：

• 快速生成配置；
• 下降框架學習成本。

隨着前端工程體系愈來愈複雜，腳手架的角色會愈來愈重要。

1.2 腳手架須要具有的要素

1.2.1 執行環境僅限本地

在討論實現一個腳手架要考慮哪些要素以前，咱們不妨先看看腳手架的執行環境。回顧前文提到的簡易前端工做流，最簡單的情形是：框架提供一套完整的本地工具鏈，腳手架、開發、開發服務器、構建和部署測試都是在本地環境執行，以下圖：

進一步的團隊會搭建CI（持續集成）平臺，將構建和部署功能遷移至雲端，這樣作便於工做流程控制和代碼統一管理。以下圖：

不論哪一種工做流，腳手架始終是在本地執行。

1.2.2 模式不固定

前端腳手架之因此沒有固定的模式，是因爲不一樣的公司對於前端工程師的定位不固定。好比有些公司的前端仍然是「切圖仔」；有些公司的前端負責瀏覽器端的全部邏輯開發可是html模板層仍然由服務端工程師維護；還有些比較前沿的團隊提倡「大前端」，負責瀏覽器層與中間層（主要承載html的渲染功能）。前端工程師定位的不固定形成了前端項目模式的不固定，腳手架天然也具有了多樣性。

不管是哪一種工做模式，一個優秀的前端腳手架都應該具有如下幾點要素：

1. 豐富但不繁瑣的配置項；
2. 與其餘功能模塊聯動，生成對應的基本配置項；
3. 自動安裝依賴；
4. 底層的高度可擴展性；
5. 支持多種運行環境，好比命令行和Node.js API。

如何理解「豐富但不繁瑣」呢？舉個例子，假設構建功能支持自動生成css sprites，配置項有兩個：

1. 是否啓用css sprites；
2. 指定散列icon目錄。

腳手架在實現針對css sprites的配置項時是否是應該將這兩個配置都開放給用戶配置呢？顯然是不須要的，腳手架只要開放是否啓用css sprites的配置項便可，由於這是影響這項功能最重要的一點，散列icon的目錄即便用戶不配置，使用默認的方案也不會形成任何不便。

另外，在實現腳手架時不該該只看到當前的需求，還應該考慮後續需求的變動和新增。因此一個優秀的腳手架應該具有高度的可擴展性，便於定製不一樣類型的方案。從這個角度來講，目前yeoman是作得最好的。

2. 開源前端腳手架方案剖析

明確了腳手架的基本工做模式，咱們不妨看看目前業內有哪些能夠借鑑的案例。咱們在這裏介紹三種形態的腳手架：

• sails是一個Node.js fullstack框架，其使用的sails generate腳手架主要是針對服務端代碼設計；
• 優酷PHP中間層框架是筆者前團隊使用的開發框架，目前並未開源。其使用的腳手架相對sails來講比較簡單，只能建立一個完整的webapp，包括Controller層和瀏覽器層代碼；
• yeoman是廣爲人知的開源腳手架工具，它自己不提供任何直接建立文件的功能，而是一個腳手架底層框架，你能夠定製本身的腳手架實現。

其中兩個是開源項目，你們能夠在Github上獲取對應的源碼。

2.1 sails - Node.js fullstack框架

sails是一個Node.js全棧框架，服務端使用MVC架構。sails generate是sails的腳手架模塊，默承認以建立如下幾種模塊的初始代碼：

• app - 建立一個新sails項目；
• api - 建立一對model和controller；
• model - 建立一個model；
• controller - 建立一個controller；
• adapter - 建立一個adapter；
• generator - 建立一個腳手架模板。

sails框架中的Adapter能夠簡單理解爲簡化model操做API的映射適配器。

你們注意最後一種類型：generator。sails在默認的腳手架基礎上，開放了自定義腳手架模板的API。

sails默認的腳手架大都是針對服務端代碼的，若是不借助其餘腳手架模板，瀏覽器端的代碼（JavaScript/CSS/Views）只能手動添加。

2.2 優酷 - PHP中間層框架

優酷的PHP中間層框架並未開源，因此就粗略的介紹一下吧。

中間層框架不涉及Model層，不涉及數據庫操做，只包括Controller和View層。這個框架的理念是：任何一個模塊都被視爲一個webapp，每一個webapp都是一個SPA，好比登陸/註冊模塊Passport、訂閱模塊Subscribe等。腳手架只能建立一種文件類型：一個完整的webapp。其中包括Controller文件、Resource文件（瀏覽器層）和路由配置文件。

因爲每一個模塊webapp都是一個SPA，包含一個Controller文件，一個view入口文件、一個入口js文件和一個css文件，因此腳手架建立的初始文件就已經夠用了，開發者只須要手動添加子模塊文件便可。同時，技術棧統一，build功能封裝完備，不須要額外配置。這種形態的腳手架基本知足了優酷PHP中間層框架的需求。

2.3 yeoman - 多是最好的開源腳手架框架

提起腳手架這三個字就不得不提yeoman這名老將。Yeoman在2012年Google I/O上首次發佈，至今已經5年的光景了。對於前端技術圈子來講，5年的時間可讓絕大部分的技術遭到淘汰，而yeoman堅持到了今天，且扔未現衰退之勢。咱們能夠短暫回顧一下5年前的前端技術，你可能會想到Knockout和Backbone，也可能會想到YUI 3，甚至可能會想起被ExtJS所支配的恐怖。而後再看看這些在當時熱火朝天的技術目前的市場狀態，是否都已經是昨日黃花垂垂老矣？而yeoman之因此能「活」這麼久，得益於它明確的定位。

yeoman的slogan是「THE WEB'S SCAFFOLDING TOOL FOR MODERN WEBAPPS」-腳手架工具，但我我的認爲稱之爲腳手架框架更爲合適。yeoman不能直接建立項目文件，它提供了一套完整的開發腳手架API，你能夠經過這些API定製符合本身業務需求的任意的腳手架方案。換句話說，yeoman不封裝任何方案，它是徹底開放、高度可擴展的。

yeoman的API具有了前文所列出的腳手架須要具有的全部要素，若是你須要開發一個屬於本身的腳手架，yeoman是最好的選擇。後續的博文會詳細介紹如何使用yeoman提供的Node.js API將其集成到工程化框架中。

3. 總結

雖然前端腳手架沒有固定形態，可是有必須具有的要素。從功能實現的角度，要考慮與業務的高度匹配；從底層框架的角度，要具有高度的可擴展性和執行環境多樣性支持。

這多是目前針對前端腳手架理念說的廢話最多的一篇文章了，哈哈。所述內容都是筆者的一些淺薄的心得，但願可以給你們一些啓發。

PS：作了一個簡單地視頻分享，你們可使用微信掃描二維碼觀看。