今時今日，做前端不用個webpack好像都被時代拋棄了一樣，每天開發的時候npm run dev，該上線了npm run build，反正執行個命令刷刷地就打包好了，你根本無需知道執行命令之後整個過程究竟幹了什麼。webpack就像個黑盒，你得小心翼翼遵循它的配置行事，配好了就萬幸。這使得我很長一段時間以來，都對webpack畢恭畢敬，能跑起來的程式碼就是最好的程式碼，千萬別亂動配置。終於有一天，我忍不住要搞清楚webpack究竟做了什麼。

我們為什麼需要webpack

去搞清楚webpack做了什麼之前，我覺得首先要思考一下我們為什麼需要webpack，它究竟解決了什麼痛點。想想我們日常搬磚的場景：1.開發的時候需要一個開發環境，要是我們修改一下程式碼儲存之後瀏覽器就自動展現最新的程式碼那就好了（熱更新服務）2.本地寫程式碼的時候，要是調後端的介面不跨域就好了（代理服務）3.為了跟上時代，要是能用上什麼ES678N等等新東西就好了（翻譯服務）4.專案要上線了，要是能一鍵壓縮程式碼啊圖片什麼的就好了（壓縮打包服務）5.我們平時的靜態資源都是放到CDN上的，要是能自動幫我把這些搞好的靜態資源懟到CDN去就好了（自動上傳服務）巴拉巴拉等等服務，那麼多你需要的服務，如果你打一個響指，這些服務都有條不紊地執行好，豈不是美滋滋！所以我們需要webpack幫我們去整合那麼多服務，而node的出現，賦予了我們去作業系統的能力，這才有了我們今天的幸福（kubi）生活(manong)。所以我覺得要根據自己的需求來使用webpack，知道自己需要什麼樣的服務，webpack能不能提供這樣的服務，如果可以，那麼這個服務應該在構建中的哪個環節被處理。

如果與輸入相關的需求，找entry（比如多頁面就有多個入口）如果與輸出相關的需求，找output（比如你需要定義輸出檔案的路徑、名字等等）如果與模組定址相關的需求，找resolve（比如定義別名alias）如果與轉譯相關的需求，找loader（比如處理sass處理es678N）如果與構建流程相關的需求，找plugin（比如我需要在打包完成後，將打包好的檔案複製到某個目錄，然後提交到git上）

抽絲剝繭之後，去理解這些的流程，你就能從webpack那一坨坨的配置中，定位到你需求被webpack處理的位置，最後加上相應的配置即可。

模組打包工具的出現

模組化可以幫助我們更好地解決複雜應用開發過程中的程式碼組織問題，但是隨著模組化思想的引入，我們的前端應用又會產生了一些新的問題，比如：

首先，我們所使用的 ES Modules 模組系統本身就存在環境相容問題。儘管現如今主流瀏覽器的最新版本都支援這一特性，但是目前還無法保證使用者的瀏覽器使用情況。所以我們還需要解決相容問題。

其次，模組化的方式劃分出來的模組檔案過多，而前端應用又執行在瀏覽器中，每一個檔案都需要單獨從伺服器請求回來。零散的模組檔案必然會導致瀏覽器的頻繁傳送網路請求，影響應用的工作效率。

最後，談一下在實現 JS 模組化的基礎上的發散。隨著應用日益複雜，在前端應用開發過程中不僅僅只有 JavaScript 程式碼需要模組化，HTML 和 CSS 這些資原始檔也會面臨需要被模組化的問題。而且從宏觀角度來看，這些檔案也都應該看作前端應用中的一個模組，只不過這些模組的種類和用途跟 JavaScript 不同。

對於開發過程而言，模組化肯定是必要的，所以我們需要在前面所說的模組化實現的基礎之上引入更好的方案或者工具，去解決上面提出的 3 個問題，讓我們的應用在開發階段繼續享受模組化帶來的優勢，又不必擔心模組化對生產環境所產生的影響。