Webpack學習指南 - 「2」基礎應用篇

一、基礎應用篇

1。1 為什麼需要 Webpack

想要理解為什麼要使用 webpack，我們先回顧下歷史，在打包工具出現之前，我們是如何在 web 中使用 JavaScript 的。在瀏覽器中執行 JavaScript 有兩種方法：

第一種方式

，引用一些指令碼來存放每個功能，比如下面這個文件：

01-why-webpack/index-1.html

<！DOCTYPE html> 千鋒大前端教研院-Webpack5學習指南 <！—— HTML 程式碼 ——>

我的HTML程式碼

<！—— 引入外部的 JavaScript 檔案 ——> <！—— 引入我自己的 JavaScript 檔案 ——>

此解決方案很難擴充套件，因為載入太多指令碼會導致網路瓶頸。同時如果你不小心更改了JavaScript檔案的載入順序，這個專案可能要崩潰。

第二種方式

，使用一個包含所有專案程式碼的大型。js 檔案，對上面的文件做改進：

01-why-webpack/index-2。html

<！DOCTYPE html> 千鋒大前端教研院-Webpack5學習指南 <！—— HTML 程式碼 ——>

我的HTML程式碼

<！—— 引入我自己的 JavaScript 檔案 ——>

這種方式解決了方式一的問題，但會導致作用域、檔案大小、可讀性和可維護性方面的問題。如何解決這些問題，接著看

1。1。1 如何解決作用域問題

早先前，我們使用 Grunt 和 Gulp 兩個工具來管理我們專案的資源。

這兩個工具稱為任務執行器，它們將所有專案檔案拼接在一起。利用了立即呼叫函式表示式（IIFE） - Immediately invoked function expressions，解決了大型專案的作用域問題；當指令碼檔案被封裝在 IIFE 內部時，你可以安全地拼接或安全地組合所有檔案，而不必擔心作用域衝突。

什麼是IIFE，參見下面的程式碼：

當函式變成立即執行的函式表示式時，表示式中的變數不能從外部訪問。

（function （） { var name = “Barry”；}）（）；// 無法從外部訪問變數 namename // 丟擲錯誤：“Uncaught ReferenceError： name is not defined”

將 IIFE 分配給一個變數，不是儲存 IIFE 本身，而是儲存 IIFE 執行後返回的結果。

var result = （function （） { var name = “Barry”； return name；}）（）；// IIFE 執行後返回的結果：result； // “Barry”

Grunt，Gulp 解決了作用域問題。但是，修改一個檔案意味著必須重新構建整個檔案。拼接可以做到很容易地跨檔案重用指令碼，卻使構建結果的最佳化變得更加困難。如何判斷程式碼是否實際被使用？

即使你只用到 lodash 中的某個函式，也必須在構建結果中加入整個庫，然後將它們壓縮在一起。大規模地實現延遲載入程式碼塊及無用程式碼的去除，需要開發人員手動地進行大量工作。

01-why-webpack/index-3.html

<！DOCTYPE html>千鋒大前端教研院-Webpack5學習指南

1。1。2 如何解決程式碼拆分問題

感謝 Node。js，

JavaScript 模組

誕生了！

Node。js 是一個 JavaScript 執行時，可以在瀏覽器環境之外的計算機和伺服器中使用。webpack 執行在 Node。js 中。

當 Node。js 釋出時，一個新的時代開始了，它帶來了新的挑戰。既然不是在瀏覽器中執行 JavaScript，現在已經沒有了可以新增到瀏覽器中的 html 檔案和 script 標籤。那麼 Node。js 應用程式要如何載入新的程式碼檔案呢？

CommonJS 問世並引入了 require 機制，它允許你在當前檔案中載入和使用某個模組。匯入需要的每個模組，這一開箱即用的功能，幫助我們解決了程式碼拆分的問題。

Node。js 已經成為一種語言、一個平臺和一種快速開發和建立快速應用程式的方式，接管了整個 JavaScript 世界。

但 CommonJS 沒有瀏覽器支援。沒有 live binding（實時繫結）。迴圈引用存在問題。同步執行的模組解析載入器速度很慢。雖然 CommonJS 是 Node。js 專案的絕佳解決方案，但瀏覽器不支援模組，我們似乎又遇到了新問題。

1。1。3 如何讓瀏覽器支援模組

在早期，我們應用Browserify和 RequireJS 等打包工具編寫能夠在瀏覽器中執行的 CommonJS 模組：

目前，我們還有一個選擇，就是來自 Web 專案的好訊息是，模組正在成為 ECMAScript 標準的官方功能。然而，瀏覽器支援不完整，版本迭代速度也不夠快，還是推薦上面兩個早期模組實現。早期的任務構建工具基於 Google 的 Closure 編譯器，要求我們手動在頂部宣告所有的依賴，開發體驗不好。

1。1。4 Webpack 搞定這一切

是否可以有一種方式，不僅可以讓我們編寫模組，而且還支援任何模組格式（至少在我們到達 ESM 之前），並且可以同時處理 resource 和 assets？

這就是 webpack 存在的原因。它是一個工具，可以打包你的 JavaScript 應用程式（支援 ESM 和 CommonJS），可以擴充套件為支援許多不同的靜態資源，例如：images， fonts 和 stylesheets。

webpack 關心效能和載入時間；它始終在改進或新增新功能，例如：非同步地載入和預先載入程式碼檔案，以便為你的專案和使用者提供最佳體驗。