這篇主要介紹一下我在玩webpack過程中的心得。通過例項介紹webpack的安裝，外掛程式使用及載入策略。感受構建工具給前端優化工作帶來的便利。曾幾何時我們的js是這樣引入頁面的
曾幾何時，我們是如上圖的方式引入js資源的，相信現在很少遇見了。近年來web前端開發領域朝著規範開發的方向演進。體現在以下兩點：
mvc研發構架。多多益處（邏輯清晰，程式注重資料與表現分離，可讀性強，利於規避和排查問題…）
構建工具層出不窮。多多益處（提公升團隊協作，以及工程運維，避免人工處理瑣碎而重複的工作）
所以，前端這麼好玩，如果還有專案沒有前後端分離的話，真的是守舊過頭了。
市面上有許多構建工具，包括grunt、gulp、browserify等，這些和webpack都是打包工具。但webpack同時也具備以下特點：
相比grunt，webpack除了具備豐富的外掛程式外，同時帶有一套載入（loader）系統。使它支援多種規範的載入方式，包括es6、commonjs、amd等方式，這是grunt、gulp所不具備的。
從**混淆的角度來看，webpack更加的極致
**分片為處理單元（而不是檔案），使得檔案的分片更為靈活。
p.s.此處只做簡單的比較，不論孰優孰劣。其實工具都能滿足需求，關鍵是看怎麼用，工具的使用背後是對前端效能優化的理解程度。
webpack執行在 nodejs之下，並且它及其外掛程式都是使用npm（nodejs的包管理工具）管理。
安裝node及npm。到nodejs官網安裝包，安裝即可
全域性安裝webpack。聯網情況下，執行命令列$npm install webpack -g即可
此至即可使用webpack了，到webpack官網去按著get start（的步驟來，感受乙個最簡單的構建過程。
然而要把webpack用好，只是跑起來是遠遠不夠的。
這裡生成了乙個topic.***.js，這個檔案本來很小，估計只有10kb左右，但構建的結果居然快1mb了。在3g網路（750kb/s）下的載入瀑布流如下圖：
這張圖（體現前端檔案載入過程）曝露了幾個問題：
上面箭頭所指的很藍色柱子，說明了大部分時間消耗在載入topic.***x.js上。
所有js檔案相關的柱子是一根結束了另一根才開始，說明不合理的檔案合併策略，導致檔案序列載入。
結果就是如底部的箭頭所看到的，頁面的載入時間太長了（3g網路，10+秒）。
觀察構建的檔案，發現原來構建工具把react、jquery等**庫合併到了topic.***x.js，造成此檔案過大。如果再加乙個activity模組呢？很明顯，activity.***.js得到類似的結果，都太大了，並且react、jquery等**庫重複被合併到activity和topic裡，如下圖。如果再加模組也會得到同樣的結果，模組越多重複載入的情況越嚴重。
可見，提取公共**，情況可以得到改善，另外，壓縮**無疑是可以使檔案變小的。
提取react、jquery等庫檔案。它們很少變化，並且到處被復用，應該被提取出來，並且得到長時間的快取。此處使用外掛程式：webpack.optimize.commonschunkplugin（webpack內建外掛程式）
**壓縮。react由700+ kb壓縮成100+ kb。此處使用外掛程式：webpack.optimize.uglifyjsplugin （webpack內建外掛程式）
處理後topic.***.js和activity.***.js都很小了，並且多了jquery.***.js和react.***.js
再看看檔案載入的瀑布流，柱子所佔比例短了，同時資源並行載入。
到此為止，這個問題算比較好地解決了，但還不夠，隨著專案越來越大，還有乙個重要因素會導致檔案很大。這部分內容放到本文的最後介紹。
快取控制要做到兩件事情，提到快取命中率
對於沒有修改的檔案，從快取中獲取檔案
對於已經修改的檔案，不要從快取中獲取
圍繞這兩點，演繹出了很多方案，此處列兩種：
從上面的截圖可以看出來，通過webpack是可以很輕鬆做到第二點的——只需要給檔名配置上[chunkhash:8]即可，其中8是指hash長度為8，預設是16。
p.s.這樣的處理效果已經很好了，但同樣有劣處，即瀏覽器給這種快取方式的快取容量太少了，只有12mb，且不分host。所以更極致的做法是以檔名為key，檔案內容為value，快取在localstorage裡，命中則從快取中取，不命中則去伺服器取，雖然快取容量也只有5mb，但是每個host是獨享這5mb的。
檔名帶上版本號後，每一次檔案變化，都需要html檔案裡手動修改引用的檔名，這種重複工作很瑣碎且容易出錯。
使用 htmlwebpackplugin 和 extracttextplugin 外掛程式可以解決此問題。
使用webpack打包，最爽的事情莫過於可以像伺服器程式設計那樣直接require檔案，看起來是同步地從伺服器上取得檔案直接就使用了。如下面的**一樣，沒有任何非同步邏輯，**很乾淨。
而，這種爽是有代價的，對於直接require模組，webpack的做法是把依賴的檔案都打包在一起，造成檔案很臃腫。
所以在寫**的時候要注意適度同步載入，同步的**會被合成並且打包在一起；非同步載入的**會被分片成乙個個chunk，在需要該模組時再載入，即按需載入，這個度是要開發者自己把握的，同步載入過多**會造成檔案過大影響載入速度，非同步過多則檔案太碎，造成過多的http請求，同樣影響載入速度。
乙個原則是：首屏需要的同步載入，首屏過後才需要的則按需載入（非同步）
以上是webpack構建工具比較好的實踐，可見，要用好還是很考驗前端效能優化的功力的，比較什麼時候同步，什麼時候非同步，如果做快取等等。
webpack4構建前端專案
在使用webpack 4.x版本構建前端專案的時候，遇到了一些坑點，這裡做一下記錄，詳細內容見注釋。用於在構建前清除dist目錄中的內容 const cleanwebpackplugin require clean webpack plugin let basewebpackconfig modul...
前端webpack構建react系列三 分模組打包
分模組打包檔案 在生產環境中，我們應該盡量減小js檔案的大小，將框架性的js裝載在乙個檔案中利用瀏覽器的快取機制節約載入資源耗費時間 分塊思路 1 react，react dom這種由第三方維護的框架，一般不會進行更新。真要更新就麻煩了，親身經歷，上級部門強制要求修復語言漏洞，硬逼著我們將某老專案p...
前端工程化（三）之webpack構建
構建，或者叫做編譯，在前端工程體系中的角色是將源 轉化為宿主瀏覽器可執行的 其核心是資源的管理。前端的產出資源包括js，css，html，分別對應的源 是 1.領先於瀏覽器實現的ecmascript規範編寫的js 2.less sass預編譯語法編寫的css 3.jade eje mustache等...