寫一個好用的多頁面webpack配置有多麻煩。。。

github倉庫

最近項目打包升級，將老的gulp換成webpack,而後很輕鬆的，增長多入口，增長rules,增長plugins好像萬事大吉了。詳細介紹如何一步一步自建一個多頁面的webpack,而後，因爲咱們是老項目，按這樣打包沒什麼一丁點問題，而後，再開發環境，新建項目，寫項目，而後發現hmr熱更新發現 ，居然要10多秒，天吶，並且發如今js裏寫的class居然沒打包過去。

下面就來談談我是怎麼解決這些坑的。

1.打包後js裏操做的class樣式，居然沒打包到css,緣由是我用了purifycss-webpack（消除冗餘的css代碼），可是沒有忽略了掃描js源代碼。這個插件確實好用哦，推薦❤️❤️❤️

2.爲何打包後，和開發環境不同，由於開發環境沒配置抽離css，因此就不會走純淨css這些插件（爲了開發環境打包速度），因此須要再加個打包後的代理服務器，能夠隨時查看效果，改bug啊，因此又新加了script/pro.js腳本

3.最重要的，開發環境熱更新要10多秒，其實多入口，webpack仍是要從新打包全部入口的文件，即便你那個頁面沒變更，形成時間久的緣由是咱們devtool:用了source-map，比較耗時間，再改過配置devtool: '#cheap-module-eval-source-map'，時間快了些，8秒左右吧，而後看了html-webpack-plugin配置hash: true,好像也快了些，可是不明顯。可是不是治根，如今頁面才30個不到，而後再考慮要不要再抽離一個但頁面入口的webpack配置，即開發的當前頁面，但想着還要複製黏貼，寫不一樣但腳本，想一想麻煩（懶啊），這時候有再webpack官網看了下，居然支持動態入口配置，so so 找到了一種比較靠譜的優化方式。文檔，

簡單的說就返回個promise對象。想着開發環境處理與生產有不少不一樣，so把開發和生產webpack分離，畢竟生產不須要動態。具體代碼

entry: () => new Promise((resolve) => resolve(webpackConf.webpackEntrys())),複製代碼

webpackEntrys函數

getAppEntry函數

entrys和commonEntry

此處遇到一個坑，剛開始是傳給是數組，結果整合成1個main.js不符合需求，後面改寫對象傳入。

注：

entry爲空，則爲打包全部頁面，爲單獨string能夠設置具體單獨打包的頁面，其實也能夠傳想要打包的數組

這個是開發者我的的配置，git設置忽略

config/self.config.js

module.exports = {  entry: "test",  env: "",  cookie: "",  devBaseUrl: ""}複製代碼

本文完，關於此腳手架（包括eslint,mock,代理，eslint,git規範化，typescript...,詳見倉庫readme說明）在實際項目中的繼續優化，會隨着項目不斷更新的，本人github還有gulp的打包腳手架，👏star