為什么選擇 webpack

想要理解為什么要使用 webpack，我們先回顧下歷史，在打包工具出現(xiàn)之前，我們是如何在 web 中使用 JavaScript 的。

在瀏覽器中運行 JavaScript 有兩種方法。第一種方式，引用一些腳本來存放每個功能；此解決方案很難擴展，因為加載太多腳本會導(dǎo)致網(wǎng)絡(luò)瓶頸。第二種方式，使用一個包含所有項目代碼的大型 ?.js? 文件，但是這會導(dǎo)致作用域、文件大小、可讀性和可維護性方面的問題。

立即調(diào)用函數(shù)表達式(IIFE) - Immediately invoked function expressions

IIFE 解決大型項目的作用域問題；當(dāng)腳本文件被封裝在 IIFE 內(nèi)部時，你可以安全地拼接或安全地組合所有文件，而不必擔(dān)心作用域沖突。

IIFE 使用方式產(chǎn)生出 Make, Gulp, Grunt, Broccoli 或 Brunch 等工具。這些工具稱為任務(wù)執(zhí)行器，它們將所有項目文件拼接在一起。

但是，修改一個文件意味著必須重新構(gòu)建整個文件。拼接可以做到很容易地跨文件重用腳本，但是卻使構(gòu)建結(jié)果的優(yōu)化變得更加困難。如何判斷代碼是否實際被使用？

即使你只用到 lodash 中的某個函數(shù)，也必須在構(gòu)建結(jié)果中加入整個庫，然后將它們壓縮在一起。如何 treeshake 代碼依賴？難以大規(guī)模地實現(xiàn)延遲加載代碼塊，這需要開發(fā)人員手動地進行大量工作。

感謝 Node.js，JavaScript 模塊誕生了

Node.js 是一個 JavaScript 運行時，可以在瀏覽器環(huán)境之外的計算機和服務(wù)器中使用。webpack 運行在 Node.js 中。

當(dāng) Node.js 發(fā)布時，一個新的時代開始了，它帶來了新的挑戰(zhàn)。既然不是在瀏覽器中運行 JavaScript，現(xiàn)在已經(jīng)沒有了可以添加到瀏覽器中的 html 文件和 script 標簽。那么 Node.js 應(yīng)用程序要如何加載新的代碼 chunk 呢？

CommonJS 問世并引入了 ?require? 機制，它允許你在當(dāng)前文件中加載和使用某個模塊。導(dǎo)入需要的每個模塊，這一開箱即用的功能，幫助我們解決了作用域問題。

npm + Node.js + modules - 大規(guī)模分發(fā)模塊

JavaScript 已經(jīng)成為一種語言、一個平臺和一種快速開發(fā)和創(chuàng)建快速應(yīng)用程序的方式，接管了整個 JavaScript 世界。

但 CommonJS 沒有瀏覽器支持。沒有 live binding(實時綁定)。循環(huán)引用存在問題。同步執(zhí)行的模塊解析加載器速度很慢。雖然 CommonJS 是 Node.js 項目的絕佳解決方案，但瀏覽器不支持模塊，因而產(chǎn)生了 Browserify, RequireJS 和 SystemJS 等打包工具，允許我們編寫能夠在瀏覽器中運行的 CommonJS 模塊。

ESM - ECMAScript 模塊

來自 Web 項目的好消息是，模塊正在成為 ECMAScript 標準的官方功能。然而，瀏覽器支持不完整，版本迭代速度也不夠快，目前還是推薦上面那些早期模塊實現(xiàn)。

依賴自動收集

傳統(tǒng)的任務(wù)構(gòu)建工具基于 Google 的 Closure 編譯器都要求你手動在頂部聲明所有的依賴。然而像 webpack 一類的打包工具自動構(gòu)建并基于你所引用或?qū)С龅膬?nèi)容推斷出依賴的圖譜。這個特性與其它的如插件 and 加載器一道讓開發(fā)者的體驗更好。

看起來都不是很好……

是否可以有一種方式，不僅可以讓我們編寫模塊，而且還支持任何模塊格式（至少在我們到達 ESM 之前），并且可以同時處理資源和資產(chǎn)？

這就是 webpack 存在的原因。它是一個工具，可以打包你的 JavaScript 應(yīng)用程序（支持 ESM 和 CommonJS），可以擴展為支持許多不同的靜態(tài)資源，例如：images, fonts 和 stylesheets。

webpack 關(guān)心性能和加載時間；它始終在改進或添加新功能，例如：異步地加載 chunk 和預(yù)取，以便為你的項目和用戶提供最佳體驗。