web應用復雜度的增加，特別是單頁面應用的風靡。組件化，工程化，自動化成了前端發(fā)展的趨勢。或者說一線的互聯(lián)網公司就是這么做的。
每個網站制作團隊都在打造自己的前端開發(fā)體系，這通常是一個東拼西湊，逐漸磨合的過程，在技術發(fā)展日新月異的今天，這樣的過程真的是不可抽象和復制的么？
一、webpack
目前市場上流行的前端工具大體分為3類，分別介紹如下。
1.工作流管理工具，比如Grunt、Gulp。
2.構建工具，比如webpack、rollup。
3.整體解決方案，比如FIS、WeFlow。
FIS是一套比較完整的前端工程化方案，它具備構建、部署、Mock服務等基本功能，但其構建功能對于目前市場較流行的技術支持度不是很理想，需要編寫插件實現。而且其生態(tài)圈不夠龐大，插件數量和質量均堪憂。此外，FIS誕生的初始目標是解決百度團隊的內部需求，不論是從功能的完整度還是對編程范式的約束上，均有一定的局限性和捆綁性，比如FIS實現自動生成CSS Sprites圖的功能需要開發(fā)者在代碼中注入特殊標記，這在一定程度上限制了代碼的可移植性。
Grunt、Gulp之類工作流管理工具本身不提供任何具體功能，所有的構建、部署等功能均由對應的插件提供。這便于項目各環(huán)節(jié)工作流程的控制，比如構建功能可以安排首先構建CSS和JS，然后構建HTML。Grunt和Gulp各自的生態(tài)圈也比較完整，但它們逐漸有了衰退之勢。圖1是來自Stack 0verflow Trends的數據。
圖1
Grunt、Gulp相關的討論話題與webpack相比下落趨勢明顯。webpack雖然是近兩年才崛起的構建工具，但其迅速發(fā)展為目前最流行的構建工具之一。其生態(tài)圈的龐大程度相比Grunt、Gulp有過之而無不及，與FIS相比更是拉開了數量級的差距，而且React、Vue等較流行的框架對應的webpack Loader均是由官方或者作者本人編寫的，可保證插件的質量和更新的及時性。即使生態(tài)圈沒有你所需的插件，webpack也提供了優(yōu)雅的生命周期和高度擴展的API，便于開發(fā)各類插件。此外，webpack在提供足夠多的構建功能的同時兼具性能優(yōu)化，比如對構建產出文件的體積進行監(jiān)控、其v2版本引入的Tree Shaking機制等。這也是我們選擇webpack作為構建內核的原因之一。rollup也是一款非常優(yōu)秀的構建工具，但由于起步較晚，目前生態(tài)還不完整。
二、工程化方案的整體架構
本地工具鏈和云管理平臺形態(tài)的前端工程化方案的主要區(qū)別在于，將構建、部署功能提升到云平臺集中管理，保證構建結果的一致性并且便于權限控制，而從各個功能模塊的實現角度考慮并沒有很大差別。所以本書以本地工具鏈形態(tài)的前端工程化方案Boi為一致性并且便于權限控制，而從各個功能模塊的實現角度考慮并沒有很大差別。所以本書以本地工具鏈形態(tài)的前端工程化方案Boi為例，剖析各功能模塊的設計方案和實現細節(jié)，同時在論述過程中兼顧云平臺的差異性對比及其解決方案。整體架構如圖1-11所示。
·暴露給用戶層的有兩種接口：命令行調用各功能模塊的接口和配置接口。
·平臺層分為4個功能模塊：腳手架、本地服務器、構建以及部署模塊。
·內核層是各個功能模塊的內核，腳手架使用Yeoman，本地服務由Node.js的Express框架承載，構建功能模塊圍繞webpack打造，部署基于SSH協(xié)議實現。
·以上所有的功能實現均是建立在Node.js平臺上的。
Boi是一款開源的前端工程化方案，讀者可以在GitHub（https：//github.com/boijs/boi)中獲取其源碼。
請注意，我們的重點并不是具體的代碼實現細節(jié)，而是通過具體案例探討前端工程化方案應該具備的功能以及設計原則。以上的具體架構和方案只是作為輔助，目的是為了便于論述和理解。
三、功能規(guī)劃
根據如圖2所示的工程化整體架構，平臺層分為4個功能模塊。
圖2 平臺層的4個功能模塊
·以Yeoman為內核的腳手架。
·以Express承載的本地服務器。
·以webpack為內核的構建系統(tǒng)。
·基于SFTP協(xié)議的遠程部署功能。
1.命令行工具
得益于龐大的生態(tài)圈，使用Node.js開發(fā)命令行工具并不是一件難事，我們可以借助優(yōu)秀的輔助工具完成，比如commander.js。
首先在package.json文件中聲明bin字段指向項目中的入口文件：
其中key的值"boi”便是命令行工具的主命令，value值"bin/boi.js”指向的是此命令調用的文件路徑。
然后在"bin/boi.js”文件中的頂部聲明此文件需要調用Node.js執(zhí)行：
#！/usr/bin/env node
隨后就可以使用commander.js定制具體的子命令了。以build命令為例：
commander.js是一個實現命令行交互的Node.js模塊，由著名的工程師TJHolowaychuk編寫。更多使用細節(jié)讀者可以參考commander.js的官方文檔。
根據前文所述的功能規(guī)劃，各功能對應的命令行命令如表1所示。
表1
2.構建功能規(guī)劃
構建系統(tǒng)是整個工程化方案中最重要也是最復雜的功能，主要解決的是前端開發(fā)層面的問題。工程化方案Boi將內置以下功能。
·ES規(guī)范的轉譯。
·CSS預編譯器支持。
·PostCSS處理hack后綴。
·自動創(chuàng)建CSS Sprites圖。
·圖片壓縮。
·小體積圖片base64內嵌。
·JavaScript模塊化規(guī)范支持。
除以上功能以外，Boi針對不同的緩存策略可以支持增量更新與覆蓋更新構建。
3.環(huán)境區(qū)分
一個前端項目的迭代周期自始至終需要經歷3個階段：開發(fā)、測試和部署上線。每個階段對應的運行環(huán)境為開發(fā)環(huán)境、測試環(huán)境和生產環(huán)境。不同的運行環(huán)境存在差異性的同時，對工程化方案的需求也不盡相同，比如開發(fā)環(huán)境需要借助Mock服務進行前端邏輯的開發(fā)、構建產出的代碼需要便于瀏覽器調試，測試環(huán)境與生產環(huán)境的異步數據接口地址不同，生產環(huán)境需要控制靜態(tài)文件體積等。工程化方案需要針對3種運行環(huán)境提供相應的功能和策略，必然會將環(huán)境相關的配置開放給用戶。Boi將3種環(huán)境具化為3個不同配置API。
.dev——開發(fā)環(huán)境。
·testing——測試環(huán)境。
·prod——生產環(huán)境。
3種環(huán)境的執(zhí)行時機分別如表2所示。
表2
用戶可以通過配置API針對不同的環(huán)境分配對應的功能和策略，隨后使用命令行工具指定執(zhí)行環(huán)境。比如測試環(huán)境使用如下配置不對JavaScript代碼進行混淆處理：
其中boi.spec是Boi提供的配置API。開發(fā)完成之后，運行以下命令構建測試環(huán)境代碼：
boi build--env testing
最終構建產出的JavaScript代碼不會經過混淆。
對環(huán)境配置功能最直觀的理解是針對不同運行環(huán)境構建產出不同的代碼內容。具體到使用層面可以與本地服務器、Mock服務、構建、部署功能模塊聯(lián)動，打造一種類似沙箱的獨立作業(yè)環(huán)境，目的是解放生產力，同時保證整個開發(fā)流程的嚴謹性和代碼質量。
四、設計原則
1.規(guī)范設計原則——用戶至上
規(guī)范分為兩部分：工程化方案自身的配置API規(guī)范以及方案對代碼編程范式的約束規(guī)范。
配置API的設計原則著重于配置項的簡潔明了，配置項可以一目了然。本書所介紹的工程化方案Boi使用webpack作為構建內核，在其外層封裝了一層簡化的配置API。webpack自身的優(yōu)異性不用贅述，但是配置復雜度非常高，并且webpack自身不提供任何具體的構建方案，用戶需要自行配置并安裝各種loader、plugin來封裝符合項目需求的具體方案。開發(fā)者往往需要花費大量的時間
習和處理webpack本身的配置，這顯然是非常影響開發(fā)效率的。Boi以外部簡化的配置API映射內部高度復雜化的webpack配置，不僅降低了一線業(yè)務開發(fā)人員對構建工具本身的學習成本，還避免了在進行自身迭代以及問題修復過程中增加的遷移成本。
編程規(guī)范的設計原則著重于代碼的可移植性，減少對代碼的捆綁性。比如前文提到的FIS在實現CSS Sprites功能時需要開發(fā)者在代碼中添加可被FIS識別的特殊標記。如果項目需要遷移到其他構建方案中，這類特殊標記便成為冗余代碼，不僅影響代碼的可讀性，而且不能保證與新的構建方案不存在沖突。工具只是輔助作用，最基本的原則是切勿喧賓奪主。
2.架構設計原則——擴展至上
除能夠解決現階段的功能需求以外，對隱含需求的支持度也是評估一套工程化方案的標準之一。即使出現新需求時目前方案不支持，也能夠以很小的成本對方案進行擴展。前端資源以及技術選型的多樣性，令可擴展性對于前端工程化方案來說尤為重要。我們在設計工程化方案架構時，應當秉持“內核輕量、擴展豐富”的原則。比如webpack本身不提供任何具化的方案，而是開放豐富的配置和擴展API供開發(fā)者封裝和擴展自己的構建方案。本書所介紹的工程化方案Boi自身只封裝了必要的功能，比如ES轉譯、CSS預編譯器支持等，對于目前流行的框架如React、Vue并不支持。但是你可以通過Boi的插件系統(tǒng)以非常小的成本對Boi進行擴展，并且這些插件是即插即用的，不會對Boi內核產生任何影響。
今天的網頁制作分享就到這了，如果您喜歡這篇文章，您可以分享給你的朋友！深圳網站建設-博納網絡編輯整理。
