為什麼使用 webpack

為了了解為什麼你應該使用 webpack，讓我們回顧一下在打包器出現之前我們如何在網路上使用 JavaScript。

有兩種方法可以在瀏覽器中執行 JavaScript。首先，為每個功能包含一個腳本；這個解決方案很難擴充，因為載入太多腳本可能會導致網路瓶頸。第二個選項是使用包含所有專案程式碼的大型 .js 檔案，但這會導致範圍、大小、可讀性和可維護性的問題。

IIFE - 立即呼叫函式表達式

IIFE 解決了大型專案的範圍問題；當腳本檔案被 IIFE 包裝時，你可以安全地串接或合併檔案，而不用擔心範圍衝突。

IIFE 的使用導致了 Make、Gulp、Grunt、Broccoli 或 Brunch 等工具。這些工具稱為任務執行器，它們會將所有專案檔案串接在一起。

然而，變更一個檔案表示你必須重建所有內容。串接讓跨檔案重複使用腳本變得更容易，但讓建置最佳化變得更困難。你如何找出程式碼是否實際上正在被使用？

即使你只使用 lodash 中的單一函式，你必須加入整個函式庫，然後將它壓縮在一起。你如何移除程式碼中的依賴關係？大規模地延遲載入程式碼區塊可能很困難，而且需要開發人員大量手動工作。

JavaScript 模組的誕生要歸功於 Node.js

Webpack 在 Node.js 上執行，這是一個 JavaScript 執行時期，可以在電腦和伺服器中，在瀏覽器環境外使用。

當 Node.js 發布時，一個新時代開始了，它帶來了新的挑戰。現在 JavaScript 不在瀏覽器中執行，Node 應用程式如何載入新的程式碼區塊？沒有可以新增到其中的 html 檔案和 script 標籤。

CommonJS 出現並引入了 require，它允許你在目前檔案中載入和使用模組。這透過在需要時匯入每個模組，來解決範圍問題。

npm + Node.js + 模組 – 大量分發

JavaScript 作為一種語言、一種平台以及一種快速開發和建立快速應用程式的途徑，正在席捲全球。

但是，瀏覽器不支援 CommonJS。沒有 即時繫結。環狀參照存在問題。同步模組解析和載入很慢。雖然 CommonJS 是 Node.js 專案的絕佳解決方案，但瀏覽器不支援模組，因此建立了 Browserify、RequireJS 和 SystemJS 等打包器和工具，讓我們能夠撰寫在瀏覽器中執行的 CommonJS 模組。

ESM - ECMAScript 模組

對於網路專案來說，好消息是模組正成為 ECMAScript 標準中的官方功能。然而，瀏覽器支援並不完整，而且打包仍然更快，目前建議使用這些早期的模組實作。

自動相依性收集

舊式的任務執行器，甚至 Google Closure Compiler 都需要您手動預先宣告所有依賴項。而 webpack 等打包器會根據匯入和匯出的內容自動建構和推論您的依賴項圖。這項功能加上其他外掛程式和載入器，能提供絕佳的開發人員體驗。

這樣不是很好嗎…

...有某個東西不僅能讓我們撰寫模組，還能支援任何模組格式（至少在我們使用 ESM 之前），並同時處理資源和資產嗎？

這就是 webpack 存在的理由。它是一個讓您能打包 JavaScript 應用程式（支援 ESM 和 CommonJS）的工具，而且可以延伸支援許多不同的資產，例如圖片、字型和樣式表。

Webpack 重視效能和載入時間；它持續改善或新增新功能，例如非同步區塊載入和預先擷取，為您的專案和使用者提供最佳體驗。