Webpack 5 正式發佈

時間 2020-10-18

標籤 javascript css 前端 java node webpack web 算法 typescript npm 欄目 JavaScript 简体版

原文原文鏈接

Webpack簡介

隨着前端發展如日沖天，前端項目也愈來愈複雜，得益於Nodejs的發展，前端模塊化、組件化、工程化也大勢所趨。伴隨着前端的模塊化和工程化，Grunt、Gulp到Webpack等項目構建和打包工具也隨之出現。javascript

前端工程化的早期，主要是解決重複任務的問題。Grunt、Gulp就是其中表明，他們的主要功能是完成文件壓縮、編譯less、sass、地址添加hash、替換等。不過，隨着前端工程化的發展，Webpack出現了，與其說是一個工程構建工具，Webpack更像是一套前端工程化解決方案。css

根據官方資料介紹，Webpack 是一個前端資源加載和打包工具。所謂的模塊就是在平時的前端開發中，用到一些靜態資源，如JavaScript、CSS、圖片等文件，Webpack就將這些靜態資源文件稱之爲模塊。 Webpack支持AMD和CommonJS，以及其餘的一些模塊系統，而且兼容多種JS書寫規範，能夠處理模塊間的依賴關係，因此具備更強大的JS模塊化的功能，它能對靜態資源進行統一的管理以及打包發佈。做爲一款 Grunt和Gulp的替代產品，Webpack受到大多數開發者的喜好，由於它可以編譯打包CSS，作CSS預處理，對JS的方言進行編譯，打包圖片，代碼壓縮等等。前端

Webpack 5

自2018 年 2 月Webpack4 發佈以來，Webpack 就一直沒有更進一步的重大更新，爲了保持 API 的一致性，舊的架構沒有作太多改變，遺留了不少的包袱。或許是沉寂過久，2020 年 10 月 10 日，Webpack 正式發佈了 5.0 版本。Webpack 5帶來了哪些新的特性呢？java

嘗試用持久性緩存來提升構建性能。
嘗試用更好的算法和默認值來改進長期緩存。
嘗試用更好的 Tree Shaking 和代碼生成來改善包大小。
嘗試改善與網絡平臺的兼容性。
嘗試在不引入任何破壞性變化的狀況下，清理那些在實現 v4 功能時處於奇怪狀態的內部結構。
試圖經過如今引入突破性的變化來爲將來的功能作準備，儘量長時間地保持在 v5 版本上。

下面就讓咱們來看一下，Webpack 5帶來的一些新的特性。node

1，清除過時功能

1.1 清理已棄用的功能

全部在 Webpack 4 標記即將過時的功能，都已在該版移除。所以在遷移到 Webpack 5 以前，請確保你在 Webpack 4 運行的構建不會有任何的功能過時警告，不然遷移到Webpack 5以後就會報錯。webpack

1.2 再也不爲Node.js 模塊自動引用Polyfills

在 Webpack 4 或以前的版本中，任何項目引用 Node.js 內置模塊都會自動添加 Polyfills，Polyfills是一個語法檢查的模版工具。不過，Webpack 5再也不爲 Node.js 內置模塊自動添加 Polyfills，Webpack 5會投入更多的精力到前端模塊的兼容性工做中。web

若是你的代碼中有引用這些 Node.js 的模塊，當須要升級到 Webpack 5版本時，請將盡可能使用前端的模塊，或者自行手動添加適合的 Polyfills。算法

2. 針對長期緩存的優化

2.1 肯定的 Chunk、模塊 ID 和導出名稱

Webpack 5新增了長期緩存的算法，這些算法在生產模式下是默認啓用的，語法格式以下。typescript

chunkIds: "deterministic" 
moduleIds: "deterministic"
mangleExports: "deterministic"

該算法以肯定性的方式爲模塊和分塊分配短的（3 或 5 位）數字 ID，這是包大小和長期緩存之間的一種權衡。因爲這些配置將使用肯定的 ID 和名稱，這意味着生成的緩存失效再也不更頻繁。npm

2.2 真正的內容哈希

當使用[contenthash]時，Webpack 5 將使用真正的文件內容哈希值。以前它 "只 "使用內部結構的哈希值。當只有註釋被修改或變量被重命名時，這對長期緩存會有積極影響。這些變化在壓縮後是不可見的。

3. 更好的開發支持

在開發模式下，默認啓用的新命名代碼塊 ID 算法爲模塊（和文件名）提供了人類可讀的名稱。
模塊 ID 由其路徑決定，相對於 context。代碼塊 ID 由代碼塊的內容決定。

因此你再也不須要使用import(/* webpackChunkName: "name" */ "module")來調試。但若是你想控制生產環境的文件名，仍是有意義的。

能夠在生產環境中使用 chunkIds: "named" 在生產環境中使用，但要確保不要不當心暴露模塊名的敏感信息。若是你不喜歡在開發中改變文件名，你能夠經過 chunkIds: "natural" 來使用舊的數字模式。

3.2 模塊聯邦

Webpack 5 增長了一個新的功能 "模塊聯邦"，它容許多個 Webpack 一塊兒工做。從運行時的角度來看，多個構建的模塊將表現得像一個巨大的鏈接模塊圖。從開發者的角度來看，模塊能夠從指定的遠程構建中導入，並以最小的限制來使用。

4. 對Web 平臺功能的全新支持

4.1 JSON 模塊

好比對 JSON 模塊，會與如今的提案保持一致，而且要求進行默認的導出，不然會有警告信息。即便使用默認導出，未使用的屬性也會被 optimization.usedExports 優化丟棄，屬性會被 optimization.mangleExports 優化打亂。

若是想用自定義的 JSON 解析器，能夠在 Rule.parser.parse 中指定一個自定義的 JSON 解析器來導入相似 JSON 的文件（如toml、yaml、json5 等）。

4.2 資源模塊

Webpack 5 如今已經對錶示資源的模塊提供了內置支持。這些模塊能夠向輸出文件夾發送一個文件，或者向 Javascript 包注入一個 DataURI。不管哪一種方式，它們都會給出一個 URL 來讓程序正常工做。

import url from "./image.png" //老方法
new URL("./image.png", import.meta.url)  //新方法

選擇 "新的方式 "語法是爲了容許在沒有打包工具的狀況下運行代碼。這種語法也能夠在瀏覽器中的原生 ECMAScript 模塊中使用。

4.3 原生 Worker 支持

當把資源的 new URL 和 new Worker/new SharedWorker/navigator.serviceWorker.register 結合起來時，Webpack 會自動爲 Web Worker 建立一個新的入口點（entrypoint），以下所示。

new Worker(new URL("./worker.js", import.meta.url))

選擇這種語法也是爲了容許在沒有打包工具的狀況下運行代碼。這種語法在瀏覽器的原生 ECMAScript 模塊中也可使用。

4.4 URIs

Webpack 5 支持在請求中處理網絡協議，好比：

支持data：支持 Base64 或原始編碼。Mimetype 能夠在module.rule中被映射到加載器和模塊類型。例如：import x from "data:text/javascript,export default 42"。
支持file：支持file文件類型。

支持http(s)：須要經過new webpack.experiments.s schemesHttp(s)UriPlugin()選擇加入。

4.5 異步模塊

Webpack 5 支持所謂的 "異步模塊"。這些模塊並非同步解析的，而是基於異步和 Promise 的。經過import 導入它們會被自動處理，不須要額外的語法，並且幾乎看不出區別。經過require()導入它們會返回一個解析到導出的 Promise。在 Webpack 中，有多種方式來擁有異步模塊，常見的方式以下：

異步的外部資源(async externals)
新規範中的 WebAssembly 模塊
使用頂層 Await 的 ECMAScript 模塊。

4.6 外部資源

Webpack 5 增長了更多的外部類型來支持更多的應用。
promise: 一個評估爲 Promise 的表達式，外部模塊是一個異步模塊，解析值做爲模塊導出使用。
import：原生的 import() 用於加載指定的請求，外部模塊是一個異步模塊，解析值做爲模塊導出，外部模塊是一個異步模塊。
module：還沒有實現，但計劃經過 import x from "..." 加載模塊。
script：經過 <script> 標籤加載一個 url，並從一個全局變量（以及它的可選屬性）中獲取輸出。外部模塊是一個異步模塊。

5. 開發體驗上的提高

5.1 通過優化的構建目標(target)

Webpack 5 容許傳遞一個目標列表，而且支持目標的版本。例如：

target: "node14" 
target: ["web", "es2020"]。

這是一個簡單的方法，爲 webpack 提供它須要肯定的全部信息：代碼塊加載機制，以及支持的語法，如箭頭函數。

5.2 統計格式

改進了統計測試格式的可讀性和冗餘性。改進了默認值，使其不那麼冗長，也適合大型構建。

5.3 進度

ProgressPlugin插件也作了一些優化，如今不只能夠統計模塊編譯的進度，也能夠統計入口和依賴。而且，以前展現進度可能會對構建性能有必定的影響，此次的升級也作了一些性能方面的優化。

5.4 自動添加惟一命名

在 Webpack 4 中，多個 Webpack 同時運行時可能會在同一個 HTML 頁面上發生衝突，由於它們使用同一個全局變量進行代碼塊加載。爲了解決這個問題，須要爲 output.jsonpFunction 配置提供一個自定義的名稱。

同時，Webpack 5 會從 package.json name 中自動推斷出一個惟一的構建名稱，並將其做爲 output.uniqueName 的默認值。因爲 package.json 中有惟一的名稱，可將 output.jsonpFunction刪除。

5.5 自動添加公共路徑

Webpack 5 會在可能的狀況下自動肯定 output.publicPath，無需開發者手動確認。

5.6 Typescript 類型

Webpack 5 能夠從源碼中生成 typescript 類型，並經過 npm 包暴露它們。若是要遷移到Webpack 5版本，須要刪除 @types/webpack。

6. 構建優化

6.1 嵌套的 tree-shaking

如今，Webpack可以跟蹤對導出的嵌套屬性的訪問，所以能夠改善從新導出命名空間對象時的 Tree Shaking（清除未使用的導出和混淆導出），以下所示。

// inner.js
export const a = 1;
export const b = 2;

// module.js
export * as inner from './inner';
// 或 
import * as inner from './inner'; export { inner };

// user.js
import * as module from './module';
console.log(module.inner.a);

6.2 內部模塊 tree-shaking

Webpack 4 沒有分析模塊的導出和引用之間的依賴關係，Webpack 5 有一個新的選項 optimization.innerGraph，在生產模式下是默認啓用的，它能夠對模塊中的標誌進行分析，找出導出和引用之間的依賴關係。

import { something } from './something';

function usingSomething() {
  return something;
}

export function test() {
  return usingSomething();
}

內部依賴圖算法會找出 something 只有在使用 test 導出時纔會使用。這容許將更多的出口標記爲未使用，並從代碼包中省略更多的代碼。

當設置"sideEffects": false時，能夠省略更多的模塊。在這個例子中，當 test 導出未被使用時，./something 將被省略。要得到未使用的導出信息，須要使用 optimization.unusedExports。要刪除無反作用的模塊，須要使用optimization.sideEffects。能夠分析如下標記：

函數聲明
類聲明
默認導出export default 或定義變量如下的
1，函數表達式

2，類表達式
3，順序表達式
4，/#__PURE__/ 表達式
5，局部變量
6，引入的捆綁(bindings)

使用 eval() 將爲一個模塊放棄這個優化，由於通過 eval 的代碼能夠引用範圍內的任何標記。這種優化也被稱爲深度範圍分析。

6.3 CommonJs Tree Shaking

曾經，Webpack不支持對 CommonJs進行導出和 require() 調用時的導出使用分析。如今，Webpack 5 增長了對一些 CommonJs 構造的支持，容許消除未使用的 CommonJs 導出，並從 require() 調用中跟蹤引用的導出名稱。

支持的構造以下：

exports|this|module.exports.xxx = ...
exports|this|module.exports = require("...") (reexport)
exports|this|module.exports.xxx = require("...").xxx (reexport)
Object.defineProperty(exports|this|module.exports, "xxx", ...)
require("abc").xxx
require("abc").xxx()
從 ESM 導入
require() 一個 ESM 模塊
被標記的導出類型 (對非嚴格 ESM 導入作特殊處理)
將來計劃支持更多的構造

6.4 開發與生產的一致性問題

Webpack正在經過改善開發模式很晚生產模式的類似性，並在開發模式上提高構建性能，避免僅在生產模式的產生的問題之間找到一個很好的平衡點。

Webpack 5 默認在兩種模式下都啓用了 "sideEffects "優化。在 Webpack 4 中，因爲 package.json 中的"sideEffects"標記不正確，這種優化致使了一些只在生產模式下出現的錯誤。r若是在開發過程當中啓用這個優化，能夠更快更容易地發現這些問題。

在不少狀況下，開發和生產都是在不一樣的操做系統上進行的，文件系統的大小寫敏感度不一樣，因此 Webpack 5 增長了一些奇怪的大小寫的警告/錯誤。

6.5 改進 target 配置

在 Webpack 4 中，"target "是在 "web" 和 "node" 之間的一個粗略的選擇（還有一些其餘的）。Webpack 5 給開發者留下了更多的選擇。target選項如今比之前影響了更多關於生成代碼的事情，好比代碼塊加載方法、代碼塊的格式、externals 是否默認被啓用等等。

此外，對於其中的一些狀況，在 "web" 和 "node" 之間的選擇過於粗略，咱們須要更多的信息。所以，咱們容許指定最低版本，例如 "node10.13"，並推斷出更多關於目標環境的屬性。

如今Webpack也容許用一個數組組合多個目標，webpack 將肯定全部目標的最小屬性。使用數組也頗有用，當使用像 "web" 或 "node" 這樣沒有提供完整信息的目標時（沒有版本號）。例如，["web", "es2020"] 結合了這兩個部分目標。

有一個目標 "browserslist"，它將使用 browserslist 類庫的數據來肯定環境的屬性。當項目中存在可用的 browserslist 配置時，這個目標也會被默認使用。當沒有可用的配置時，默認使用 "web" 目標。

6.6 代碼塊拆分與模塊大小

如今，Webpack 支持對模塊按照大小進行拆分。SplitChunksPlugin 插件知道如何處理這些不一樣模塊的大小，併爲它們設置 minSize 和 maxSize，以下所示。

module.exports = {
  optimization: {
    splitChunks: {
      minSize: {
        javascript: 30000,
        webassembly: 50000,
      },
    },
  },
};

7.性能優化

7.1 持久緩存

如今有一個文件系統緩存，它是可選的，能夠經過如下配置啓用。

module.exports = {
  cache: {
    // 1. 將緩存類型設置爲文件系統
    type: 'filesystem',

    buildDependencies: {
      // 2. 將你的config 添加爲 buildDependency，以便在改變 config 時得到緩存
      config: [__filename],
      // 3. 若是有其餘的東西須要被構建依賴，能夠在這裏添加它們
      // 注意，webpack、加載器和全部從你的配置中引用的模塊都會被自動添加
    },
  },
};

說明：
默認狀況下，Webpack 假定 Webpack 所在的 node_modules 目錄只被包管理器修改，對 node_modules 來講，哈希值和時間戳會被跳過。出於性能考慮，只使用包名和版本。只要不指定resolve.symlinks: false，Symlinks(即npm/yarn link)就沒有問題(不管如何都要避免)。不要直接編輯 node_modules 中的文件，除非你用 snapshot.managedPaths: []以剔除該優化。當使用 Yarn PnP 時，webpack 假設 yarn 緩存是不可改變的（一般是這樣），此時可使用 snapshot.immutablePaths: [] 來退出這個優化。

緩存將默認存儲在 node_modules/.cache/webpack（當使用 node_modules 時）或 .yarn/.cache/webpack（當使用 Yarn PnP 時）中。當全部的插件都正確處理緩存時，你可能永遠都不須要手動刪除它。

許多內部插件也會使用持久性緩存。例如 SourceMapDevToolPlugin (緩存 SourceMap 的生成)或 ProgressPlugin (緩存模塊數量)

持久性緩存將根據使用狀況自動建立多個緩存文件，以優化對緩存的讀寫訪問。默認狀況下，時間戳將用於開發模式的快照，而文件哈希將用於生產模式。文件哈希也容許在 CI 中使用持久性緩存。

7.2 編譯器閒置和關閉

編譯器如今須要在使用後關閉。編譯器如今會進入和離開空閒狀態，而且有這些狀態的鉤子。插件可能會使用這些鉤子來作不重要的工做。(即將持久緩存緩慢地將緩存存儲到磁盤上)。在編譯器關閉時--全部剩餘的工做應該儘量快地完成。一個回調標誌着關閉完成。

插件和它們各自的做者應該預料到，有些用戶可能會忘記關閉編譯器。因此，全部的工做最終也應該在空閒狀態下完成。當工做正在進行時，應該防止進程退出。webpack() 用法在被傳遞迴調時自動調用close。

7.3 文件生成

Webpack 過去老是在第一次構建時發出全部的輸出文件，但在增量（觀察）構建時跳過了寫入未更改的文件。假設在 Webpack 運行時，沒有任何其餘東西改變輸出文件。
增長了持久性緩存後，即便在重啓 Webpack 進程時，也會有相似監聽的體驗。因此，如今Webpack 會檢查輸出目錄中現有的文件，並將其內容與內存中的輸出文件進行比較，只有當文件被改變時，它纔會執行寫入文件操做。
這隻在第一次構建時進行。任何增量構建都會在運行中的 webpack 進程中生成新的資產時寫入文件。

8. 重大問題

8.1 單一文件目標的代碼分割

只容許啓動單個文件的目標（如 node、WebWorker、electron main）如今支持運行時自動加載引導所需的依賴代碼片斷。所以，容許對這些目標使用 chunks: "all" 和 optimization.runtimeChunk。
請注意，若是目標的代碼塊加載是異步的，這使得初始評估也是異步的。當使用 output.library 時，這多是一個問題，由於如今導出的值是一個 Promise處理後的值。

8.2 新的解析器

enhanced-resolve 更新到了 v5，有如下改進：

追蹤更多的依賴關係，好比丟失的文件。
別名可能有多種選擇
如今能夠別名爲 false 了。
支持 exports 和 imports 字段等功能。
性能提升

8.3 沒有 JS 的代碼塊

不包含 JS 代碼的塊，將再也不生成 JS 文件。這就容許有隻包含 CSS 的代碼塊。

9.將來計劃

9.1 實驗特性

在 webpack 5 中，有一個新的 experiments 配置選項，容許啓用實驗性功能。這使得哪些功能被啓用/使用變得很清楚。

雖然 webpack 遵循語義版本化，但它會對實驗性功能進行例外處理。實驗性功能可能會在 webpack 的次要版本中包含破壞性的變化。當這種狀況發生時，咱們會在變動日誌中添加一個明確的註釋。這將使咱們可以更快地迭代實驗性功能，同時也使咱們可以在主要版本上爲穩定的功能停留更長時間。

而且，如下的實驗功能也會隨 Webpack 5 一塊兒發佈。

舊的 WebAssembly 支持，就像 Webpack 4 同樣 (experiments.syncWebAssembly)
根據更新的規範(experiments.asyncWebAssembly)，新增 WebAssembly 支持。這使得一個 WebAssembly 模塊成爲一個異步模塊。
頂層的 Await第三階段提案(experiments.topLevelAwait)在頂層使用 await 使該模塊成爲一個異步模塊。
以模塊的形式生成代碼包 (experiments.outputModule)這就從代碼包中移除了包裝器 IIFE，執行嚴格模式，經過 <script type="module"> 進行懶惰加載，並在模塊模式下最小化壓縮。

9.2 最小 Node.js 版本

最低支持的 Node.js 版本從 6 增長到 10.13.0(LTS)。

10.內部架構變動

下面是一些Webpack 5架構方面的變動：

10.1 新的插件運行順序

如今 webpack 5 中的插件在應用配置默認值以前就會被應用。這使得插件能夠應用本身的默認值，或者做爲配置預設。但這也是一個突破性的變化，由於插件在應用時不能依賴配置值的設置。
遷移：只在插件鉤子中訪問配置。或者最好徹底避免訪問配置，並經過構造函數獲取選項。

10.2 運行時模塊

大部分的運行時代碼被移到了所謂的"運行時模塊"中。這些特殊模塊負責添加運行時代碼。它們能夠被添加到任何塊中，但目前老是被添加到運行時塊中。
"運行時需求"控制哪些運行時模塊（或核心運行時部件）被添加到代碼包中。這確保了只有使用的運行時代碼纔會被添加到代碼包中。將來，運行時模塊也能夠添加到按需加載的塊中，以便在須要時加載運行時代碼。

在大多數狀況下，核心運行代碼時容許內聯入口模塊，而不是用 __webpack_require__ 來調用它。若是代碼包中沒有其餘模塊，則根本不須要使用__webpack_require__。這與模塊合併很好地結合在一塊兒，即多個模塊被合併成一個模塊。在最好的狀況下，根本不須要運行時代碼。

遷移：若是你在插件中注入運行時代碼到 Webpack 運行時，能夠考慮使用 RuntimeModules 來代替。

10.3 序列化

咱們添加了一個序列化機制，以容許在 webpack 中對複雜對象進行序列化。它有一個可選的語義，因此那些應該被序列化的類須要被明確地標記出來（而且實現它們的序列化）。大多數模塊、全部的依賴關係和一些錯誤都已經這樣作了。

遷移：當使用自定義模塊或依賴關係時，建議將它們實現成可序列化的，以便從持久化緩存中獲益。

10.4 用於緩存的插件

增長了一個帶有插件接口的 Cache 類。該類可用於寫入和讀取緩存。根據配置的不一樣，不一樣的插件能夠爲緩存添加功能。MemoryCachePlugin 增長了內存緩存功能。FileCachePlugin 增長了持久性（文件系統）緩存。FileCachePlugin 使用序列化機制將緩存項目持久化到磁盤上或從磁盤上恢復。

10.5 Tapable 插件升級

Webpack 3 插件的 compat 層已經被移除，而且它在 Webpack 4 中已經被取消了，一些較少使用的 tapable API 被刪除或廢棄。

10.6 Main/Chunk/ModuleTemplate 廢棄

打包模板已經重構。MainTemplate/ChunkTemplate/ModuleTemplate 被廢棄，如今 JavascriptModulesPlugin 負責 JS 模板。

在那次重構以前，JS 輸出由 Main/ChunkTemplate 處理，而另外一個輸出（即 WASM、CSS）則由插件處理。重構後這一點被改變了，全部的輸出都由他們的插件處理。

依然能夠侵入部分模板。鉤子如今在 JavascriptModulesPlugin 中，而不是 Main/ChunkTemplate 中。(是的，插件也能夠有鉤子，我稱之爲附加鉤子。)有一個兼容層，因此 Main/Chunk/ModuleTemplate 仍然存在，但只是將 tap 調用委託給新的鉤子位置。

10.7 入口文件的新增配置

在 Webpack 5 中，入口文件除了字符串、字符串數組，也可使用描述符進行配置了，以下所示。

module.exports = {
  entry: {
    catalog: {
      import: './catalog.js',
    },
  },
};

此外，咱們也能夠定義輸出的文件名，以前都是經過 output.filename 進行定義的，以下所示。

module.exports = {
  entry: {
    about: { import: './about.js', filename: 'pages/[name][ext]' },
  },
};

另外，入口文件的配置，新增了文件依賴定義、生成類庫的格式類型（commonjs 或 amd），也能夠設置運行時的名字，以及代碼塊加載的方式，更多細節能夠參考完整的發佈記錄。

10.8 排序與ID

Webpack 曾經在編譯階段以特定的方式對模塊和代碼塊進行排序，以遞增的方式分配 ID。如今再也不是這樣了。順序將再也不用於 ID 的生成，取而代之的是，ID 的生成徹底由插件進行控制，而且優化模塊和代碼塊順序的鉤子已經被移除。

10.9 從數組到集合(Set)

Compilation.modules 如今是一個集合
Compilation.chunks 如今是一個集合
Chunk.files 如今是一個集合

10.10 文件系統與信息變動

在Webpack 5 中，一個是須要使用 Compilation.fileSystemInfo 替代 file/contextTimestamps，獲取文件的時間戳信息，另外一個是新增Compiler.modifiedFiles 以便更容易引用更改後的文件。
另外，還新增了一個相似於 compiler.inputFileSystem 和 compiler.outputFileSystem 的新 API compiler.intermediateFileSystem，用於全部不被認爲是輸入或輸出的 fs 操做，如寫入 records，緩存或輸出 profiling。

10.11 模塊熱替換

HMR 運行時已被重構爲運行時模塊。HotUpdateChunkTemplate 已被合併入 ChunkTemplate 中。ChunkTemplates 和 plugins 也應處理 HotUpdateChunk 了。

HMR 運行時的 Javascript 部分已從核心 HMR 運行時鐘分離了出來。其餘模塊類型如今也可使用它們本身的方式處理 HMR。在將來，這將使得 HMR 處理諸如 mini-css-extract-plugin 或 WASM 模塊。

遷移：此爲新功能，無需遷移。
import.meta.webpackHot 公開了與 module.hot 相同的 API。固然能夠在 ESM 模塊（.mjs，package.json 中的 type: "module"）中使用，這些模塊不能訪問 module。

10.12 工做隊列

Webpack 曾經經過函數調用函數的形式來進行模塊處理，還有一個 semaphore 選項限制並行性。Compilation.semaphore 已被移除，如今可使用異步隊列處理，每一個步驟都有獨立的隊列：

Compilation.factorizeQueue：爲一組 dependencies 調用模塊工廠。
Compilation.addModuleQueue：將模塊添加到編譯隊列中（可使用緩存恢復模塊）
Compilation.buildQueue：必要時構建模塊（可將模塊存儲到緩存中）
Compilation.rebuildQueue：如需手動觸發，則會從新構建模塊
Compilation.processDependenciesQueue：處理模塊的 dependencies。

這些隊列會有一些 hook 來監聽並攔截工做的進程。將來，多個編譯器會同時工做，能夠經過攔截這些隊列來進行編譯工做的編排。

10.13 模塊和 chunk 圖

Webpack 曾經在依賴關係中存儲了已解析的模塊，並在 chunk 中存儲引入的模塊。但現已發生變化。全部關於模塊在模塊圖中如何鏈接的信息，如今都存儲在 ModulGraph 的 class 中。全部關於模塊與 chunk 如何鏈接的信息如今都已存儲在 ChunkGraph 的 class 中。依賴於 chunk 圖的信息也存儲在相關的 class 中。

如下列舉一些模塊的信息已被移動的例子：

Module connections -> ModuleGraph
Module issuer -> ModuleGraph
Module optimization bailout -> ModuleGraph (TODO: check if it should ChunkGraph instead)

當從緩存中恢復模塊時，Webpack 會將模塊從圖中斷開。如今已無需這麼作。一個模塊不存儲圖形的任何信息，技術上能夠在多個圖形中使用。這會使得緩存變得更加容易。這部分變化中大多數都有一個適配層，當使用時，它會打印一個棄用警告。

10.14 模塊 Source Types

如今，模塊必須經過 Module.getSourceTypes() 來定義它們支持的源碼類型。根據這一點，不一樣的插件會用這些類型調用 source()。對於源類型爲 Javascript 的 JavascriptModulesPlugin 會將源代碼嵌入到 bundle 中。源類型 Webassembly 的 WebAssemblyModulesPlugin 會 emit 一個 wasm 文件。同時，也支持自定義源類型，例如，mini-css-extract-plugin 會使用源類型爲 stylesheet 將源碼嵌入到 css 文件中。

模塊類型與源類型間沒有關係。即便模塊類型爲 Json，也可使用源類型爲 Javascript 和模塊類型爲 webassembly/experimental 的 Javascript 和 Webassembly。

10.15 全新的觀察者

Webpack 所使用的觀察者已重構。它以前使用的是 chokidar 和原生依賴 fsevents（僅在 OSX 上）。如今它在只基於原生的 Node.js 中的 fs，這意味着在 webpack 中已經沒有原生依賴了。

它還能在監聽時捕捉更多關於文件系統的信息。目前，它還能夠捕獲 mtimes 和監視事件時間，以及丟失文件的信息。爲此，WatchFileSystem API 作了一點小改動。在修改的同時，咱們還將 Arrays 轉換爲 Sets，Objects 轉換爲 Maps。

10.16 SizeOnlySource after emit

Webpack 如今使用 SizeOnlySource 替換 Compilation.assets 中的 Sources，以減小內存佔用狀況。

10.17 ExportsInfo

重構了模塊導出信息的存儲方式。ModuleGraph 如今爲每一個 Module 提供了一個 ExportsInfo，它用於存儲每一個 export 的信息。若是模塊僅以反作用的方式使用，它還存儲了關於未知 export 的信息，而且每一個 export都會存儲如下信息：

是否使用 export? 是否使用並不肯定。
是否提供 export? 是否提供並不肯定。
可否重命名 export 名? 是否重命名，也不肯定
若是 export 已從新命名，則爲新名稱。
嵌套的 ExportsInfo，若是 export 是一個含有附加信息的對象，那麼它自己就是一個對象。

10.18 代碼生成階段

編譯的代碼生成功能做爲單獨的編譯階段。它再也不隱藏在 Module.source() 和 Module.getRuntimeRequirements() 中運行了。這應該會使得流程更加簡潔。它還運行報告該階段的進度。並使得代碼生成在剖析時更加清晰可見。

遷移時，Module.source() 和 Module.getRuntimeRequirements() 已棄用，而後使用 Module.codeGeneration() 代替。

10.19 依賴關係參考

Webpack 曾經有一個單一的方法和類型來表示依賴關係的引用（Compilation.getDependencyReference 會返回一個 DependencyReference）該類型用於引入關於該引用的全部信息，如被引用的模塊，已經引入了哪些 export，若是是弱引用，還須要訂閱一些相關信息。把全部這些信息構建在一塊兒，拿到參考的成本就很高，並且很頻繁（每次有人須要一個信息）。

在 Webpack5 中，這部分代碼庫被重構了，方法進行了拆分：

引用的模塊能夠從 ModuleGraphConnection 中讀取
引入的導出名，能夠經過 Dependency.getReferencedExports() 獲取
Dependency 的 class 上會有一個 weak 的 flag
排序只與 HarmonyImportDependencies 相關，能夠經過 sourceOrder 屬性獲取

10.20 Presentational Dependencies

這是 NormalModules 的一種新 Dependencies 類型：Presentational Dependencies。這些 dependencies 只在代碼生成階段使用，但在模塊圖構建過程當中未使用。因此它們永遠不能引用模塊或影響導出/導入。這些依賴關係的處理成本較低，Webpack 會盡量地使用它們。

10.21 棄用 loaders

null-loader已被棄用，可使用下面的寫法進行替換。

module.exports = {
  resolve: {
    alias: {
      xyz$: false,
    },
  },
};
// 或者使用絕對路徑
module.exports = {
  resolve: {
    alias: {
      [path.resolve(__dirname, '....')]: false,
    },
  },
};

總的來講，Webpack 5 的大部分工做都圍繞優化進行展開，去除了 Webpck 4 中有廢棄的內容，新增了長期緩存，優化了內核等內容。

參考文檔：中文文檔：webpack.docschina.org