0、目錄
1、爲什麼選擇 webpack
想要理解爲什麼要使用 webpack，我們先回顧下歷史，在打包工具出現之前，我們是如何在 web 中使用 JavaScript 的。
在瀏覽器中運行 JavaScript 有兩種方法。第一種方式，引用一些腳本來存放每個功能；此解決方案很難擴展，因爲加載太多腳本會導致網絡瓶頸。第二種方式，使用一個包含所有項目代碼的大型 .js 文件，但是這會導致作用域、文件大小、可讀性和可維護性方面的問題。
2、立即調用函數表達式 - Immediately invoked function expressions
IIFE 解決大型項目的作用域問題；當腳本文件被封裝在 IIFE 內部時，你可以安全地拼接或安全地組合所有文件，而不必擔心作用域衝突。
這種方式產生出 Make, Gulp, Grunt, Broccoli 或 Brunch 等工具。這些工具稱爲任務執行器，它們將所有項目文件拼接在一起。
但是，修改一個文件意味着必須重新構建整個文件。拼接可以做到很容易地跨文件重用腳本，但是卻使構建結果的優化變得更加困難。如何判斷代碼是否實際被使用？
即使你只用到 lodash 中的某個函數，也必須在構建結果中加入整個庫，然後將它們壓縮在一起。如何 treeshake 代碼依賴？難以大規模地實現延遲加載代碼塊，這需要開發人員手動地進行大量工作。
3、感謝 Node.js，JavaScript 模塊誕生了
Node.js 是一個 JavaScript 運行時，可以在瀏覽器環境之外的計算機和服務器中使用。webpack 運行在 Node.js 中。
當 Node.js 發佈時，一個新的時代開始了，它帶來了新的挑戰。既然不是在瀏覽器中運行 JavaScript，現在已經沒有了可以添加到瀏覽器中的 html 文件和 script 標籤。那麼 Node.js 應用程序要如何加載新的代碼 chunk 呢？
CommonJS 問世並引入了 require 機制，它允許你在當前文件中加載和使用某個模塊。導入需要的每個模塊，這一開箱即用的功能，幫助我們解決了作用域問題。
4、npm + Node.js + modules - 大規模分發模塊
JavaScript 已經成爲一種語言、一個平臺和一種快速開發和創建快速應用程序的方式，接管了整個 JavaScript 世界。
但 CommonJS 沒有瀏覽器支持。沒有 live binding(實時綁定)。循環引用存在問題。同步執行的模塊解析加載器速度很慢。雖然 CommonJS 是 Node.js 項目的絕佳解決方案，但瀏覽器不支持模塊。因而創建了 Browserify, RequireJS 和 SystemJS 等打包工具，允許我們編寫能夠在瀏覽器中運行的 CommonJS 模塊。
5、ESM - ECMAScript 模塊
來自 Web 項目的好消息是，模塊正在成爲 ECMAScript 標準的官方功能。然而，瀏覽器支持不完整，版本迭代速度也不夠快，目前還是推薦上面那些早期模塊實現。
6、看起來都不是很好……
是否可以有一種方式，不僅可以讓我們編寫模塊，而且還支持任何模塊格式（至少在我們到達 ESM 之前），並且可以同時處理資源和資產？
這就是 webpack 存在的原因。它是一個工具，可以打包你的 JavaScript 應用程序（支持 ESM 和 CommonJS），可以擴展爲支持許多不同的資產，例如：images, fonts 和 stylesheets。 w webpack 關心性能和加載時間；它始終在改進或添加新功能，例如：異步地加載 chunk 和預取，以便爲你的項目和用戶提供最佳體驗。