現在前端模組化、es6、MVVM這麼火，附帶的在學習使用這些知識時或多或少都會接觸到webpack。 這裡我不會去講webpack本身的知識，這些東西都爛大街了一搜一大把。
通過本文你將會了解到如何將webpack引入到一個傳統的多頁面專案（如：商城）中去，藉助webpack讓我們能夠使用es6、能夠實現我們的模組化方案
注意：僅指中小型多頁面專案
一，傳統多頁面的特點
- 一個頁面對應一個url
- 功能串插混亂，一個頁面要引入很多執行不到的程式碼
- 開發和版本迭代時程式碼管理難度大
- 使用檔案hash控制快取難度大，使用版本號控制快取釋出時又會出現各種快取更新問題
二，思考
- 功能複用和程式碼組織通過模組化的方式很容易解決這個痛點
- 多url頁面如何引入帶hash的資原始檔
- 使用webpack單入口的方式？最終導致的結果是單個資原始檔過大，無法有效利用快取也會導致單次檔案下載時間過長，所以不可取
- 使用webpack多入口的方式？多url對應多入口貌似很有搞頭
現在問題又來了，使用多入口必定設計到拆分的概念，將原本一個入口拆分成多個入口這需要一個什麼樣的標準呢，這就是接下來要講的核心內容了
三，解決方案
有後端開發（如php）經驗的同學知道在寫業務邏輯程式碼時主要涉及到的是MVC中的C層（controller）,controller中會實現一系列的action，controller/action的組合也就實現了我們的頁面url(www.xxx.com/controllerName/actionName)
1，現在我們來捋一捋上面的過程
- 一個controller裡面會有多個action
- controller/action 對應一個url頁面
- controller/* 表示一系列處於同一個controlelr下的url頁面
- controller表示有業務關聯的一系列url頁面
現在不知道大家有沒有理解清楚，後端將有業務關聯的action寫到同一個controller中，所以前端同理可以將有業務關聯的多個url頁面打包起來看成一個SPA應用（文中提到的SPA非真正的SPA，只是用來幫助理解）
2，開始拆分了（以商城系統為例）
- 首頁SPA（首頁比較重要一般獨立出來）
- 商品SPA(商品詳情頁，商品列表，商品搜尋頁)
- 購物車SPA(購物車列表，付款頁，結算頁)
- 使用者SPA（登入，註冊，找回密碼一系列）
- 會員中心SPA（一般的商城會員中心功能比較簡單可以不用拆分，如果比較複雜自己可以按照同樣的思路進行拆分）
- 促銷SPA（視商城的業務定）
- 活動頁（活動頁一般不建議進行打包，可單獨使用傳統的方案）
這樣我們就把商城這一個按業務拆分為多個（首頁、商品、購物車、使用者、會員中心、促銷...）
3,一圖勝千言
隨手畫的，哈哈哈~
4，專案目錄結構
5，webpack入口配置
總結
從頭看一下整個過程
- 按業務將整個系統拆分為多個前端專案（SPA）
- 打包SPA包含的url頁面程式碼
整個過程經歷了從一到多，再從多到一
webpack這麼火你還沒用嗎？還不趕快嘗試下。已經在使用了？也希望本文能給你不一樣的思路
文中有表述不準確的或者有相關建議的歡迎在下面留言（'.'）