多圖詳解，一次性搞懂 Webpack Loader
Webpack 是一個模塊化打包工具，它被廣泛地應用在前端領域的大多數項目中。利用 Webpack 我們不僅可以打包 JS 文件，還可以打包圖片、CSS、字體等其他類型的資源文件。而支持打包非 JS 文件的特性是基於 Loader 機制來實現的。因此要學好 Webpack，我們就需要掌握 Loader 機制。本文阿寶哥將帶大家一起深入學習 Webpack 的 Loader 機制，閱讀完本文你將瞭解以下內容：
-
Loader 的本質是什麼？
-
Normal Loader 和 Pitching Loader 是什麼？
-
Pitching Loader 的作用是什麼？
-
Loader 是如何被加載的？
-
Loader 是如何被運行的？
-
多個 Loader 的執行順序是什麼？
-
Pitching Loader 的熔斷機制是如何實現的？
-
Normal Loader 函數是如何被運行的？
-
Loader 對象上
raw屬性有什麼作用？ -
Loader 函數體中的
this.callback和this.async方法是哪裏來的？ -
Loader 最終的返回結果是如何被處理的？
一、Loader 的本質是什麼？
由上圖可知，Loader 本質上是導出函數的 JavaScript 模塊。所導出的函數，可用於實現內容轉換，該函數支持以下 3 個參數：
/**
* @param {string|Buffer} content 源文件的內容
* @param {object} [map] 可以被 https://github.com/mozilla/source-map 使用的 SourceMap 數據
* @param {any} [meta] meta 數據，可以是任何內容
*/
function webpackLoader(content, map, meta) {
// 你的webpack loader代碼
}
module.exports = webpackLoader;瞭解完導出函數的簽名之後，我們就可以定義一個簡單的 simpleLoader：
function simpleLoader(content, map, meta) {
console.log("我是 SimpleLoader");
return content;
}
module.exports = simpleLoader;以上的 simpleLoader 並不會對輸入的內容進行任何處理，只是在該 Loader 執行時輸出相應的信息。Webpack 允許用戶爲某些資源文件配置多個不同的 Loader，比如在處理 .css 文件的時候，我們用到了 style-loader 和 css-loader，具體配置方式如下所示：
webpack.config.js
const path = require('path');
module.exports = {
entry: './src/index.js',
output: {
filename: 'bundle.js',
path: path.resolve(__dirname, 'dist'),
},
module: {
rules: [
{
test: /\.css$/i,
use: ['style-loader', 'css-loader'],
},
],
},
};Webpack 這樣設計的好處，是可以保證每個 Loader 的職責單一。同時，也方便後期 Loader 的組合和擴展。比如，你想讓 Webpack 能夠處理 Scss 文件，你只需先安裝 sass-loader，然後在配置 Scss 文件的處理規則時，設置 rule 對象的 use 屬性爲 ['style-loader', 'css-loader', 'sass-loader'] 即可。
二、Normal Loader 和 Pitching Loader 是什麼？
2.1 Normal Loader
Loader 本質上是導出函數的 JavaScript 模塊，而該模塊導出的函數（若是 ES6 模塊，則是默認導出的函數）就被稱爲 Normal Loader。需要注意的是，這裏我們介紹的 Normal Loader 與 Webpack Loader 分類中定義的 Loader 是不一樣的。在 Webpack 中，loader 可以被分爲 4 類：pre 前置、post 後置、normal 普通和 inline 行內。其中 pre 和 post loader，可以通過 rule 對象的 enforce 屬性來指定：
// webpack.config.js
const path = require("path");
module.exports = {
module: {
rules: [
{
test: /\.txt$/i,
use: ["a-loader"],
enforce: "post", // post loader
},
{
test: /\.txt$/i,
use: ["b-loader"], // normal loader
},
{
test: /\.txt$/i,
use: ["c-loader"],
enforce: "pre", // pre loader
},
],
},
};瞭解完 Normal Loader 的概念之後，我們來動手寫一下 Normal Loader。首先我們先來創建一個新的目錄：
$ mkdir webpack-loader-demo然後進入該目錄，使用 npm init -y 命令執行初始化操作。該命令成功執行後，會在當前目錄生成一個 package.json 文件：
{
"name": "webpack-loader-demo",
"version": "1.0.0",
"description": "",
"main": "index.js",
"scripts": {
"test": "echo \"Error: no test specified\" && exit 1"
},
"keywords": [],
"author": "",
"license": "ISC"
}提示：本地所使用的開發環境：Node v12.16.2；Npm 6.14.4；
接着我們使用以下命令，安裝一下 webpack 和 webpack-cli 依賴包：
$ npm i webpack webpack-cli -D安裝完項目依賴後，我們根據以下目錄結構來添加對應的目錄和文件：
├── dist # 打包輸出目錄
│ └── index.html
├── loaders # loaders文件夾
│ ├── a-loader.js
│ ├── b-loader.js
│ └── c-loader.js
├── node_modules
├── package-lock.json
├── package.json
├── src # 源碼目錄
│ ├── data.txt # 數據文件
│ └── index.js # 入口文件
└── webpack.config.js # webpack配置文件dist/index.html
<!DOCTYPE html>
<html lang="zh-cn">
<head>
<meta charset="UTF-8">
<meta http-equiv="X-UA-Compatible" content="IE=edge">
<meta >
<title>Webpack Loader 示例</title>
</head>
<body>
<h3>Webpack Loader 示例</h3>
<p id="message"></p>
<script src="./bundle.js"></script>
</body>
</html>src/index.js
import Data from "./data.txt"
const msgElement = document.querySelector("#message");
msgElement.innerText = Data;src/data.txt
大家好，我是阿寶哥loaders/a-loader.js
function aLoader(content, map, meta) {
console.log("開始執行aLoader Normal Loader");
content += "aLoader]";
return `module.exports = '${content}'`;
}
module.exports = aLoader;在 aLoader 函數中，我們會對 content 內容進行修改，然後返回 module.exports = '${content}' 字符串。那麼爲什麼要把 content 賦值給 module.exports 屬性呢？這裏我們先不解釋具體的原因，後面我們再來分析這個問題。
loaders/b-loader.js
function bLoader(content, map, meta) {
console.log("開始執行bLoader Normal Loader");
return content + "bLoader->";
}
module.exports = bLoader;loaders/c-loader.js
function cLoader(content, map, meta) {
console.log("開始執行cLoader Normal Loader");
return content + "[cLoader->";
}
module.exports = cLoader;在 loaders 目錄下，我們定義了以上 3 個 Normal Loader。這些 Loader 的實現都比較簡單，只是在 Loader 執行時往 content 參數上添加當前 Loader 的相關信息。爲了讓 Webpack 能夠識別 loaders 目錄下的自定義 Loader，我們還需要在 Webpack 的配置文件中，設置 resolveLoader 屬性，具體的配置方式如下所示：
webpack.config.js
const path = require("path");
module.exports = {
entry: "./src/index.js",
output: {
filename: "bundle.js",
path: path.resolve(__dirname, "dist"),
},
mode: "development",
module: {
rules: [
{
test: /\.txt$/i,
use: ["a-loader", "b-loader", "c-loader"],
},
],
},
resolveLoader: {
modules: [
path.resolve(__dirname, "node_modules"),
path.resolve(__dirname, "loaders"),
],
},
};當目錄更新完成後，在 webpack-loader-demo 項目的根目錄下運行 npx webpack 命令就可以開始打包了。以下內容是阿寶哥運行 npx webpack 命令之後，控制檯的輸出結果：
開始執行cLoader Normal Loader
開始執行bLoader Normal Loader
開始執行aLoader Normal Loader
asset bundle.js 4.55 KiB [emitted] (name: main)
runtime modules 937 bytes 4 modules
cacheable modules 187 bytes
./src/index.js 114 bytes [built] [code generated]
./src/data.txt 73 bytes [built] [code generated]
webpack 5.45.1 compiled successfully in 99 ms通過觀察以上的輸出結果，我們可以知道 Normal Loader 的執行順序是從右到左。此外，當打包完成後，我們在瀏覽器中打開 dist/index.html 文件，在頁面上你將看到以下信息：
Webpack Loader 示例
大家好，我是阿寶哥[cLoader->bLoader->aLoader]由頁面上的輸出信息 ” 大家好，我是阿寶哥 [cLoader->bLoader->aLoader]“ 可知，Loader 在執行的過程中是以管道的形式，對數據進行處理，具體處理過程如下圖所示：
現在你已經知道什麼是 Normal Loader 及 Normal Loader 的執行順序，接下來我們來介紹另一種 Loader —— Pitching Loader。
2.2 Pitching Loader
在開發 Loader 時，我們可以在導出的函數上添加一個 pitch 屬性，它的值也是一個函數。該函數被稱爲 Pitching Loader，它支持 3 個參數：
/**
* @remainingRequest 剩餘請求
* @precedingRequest 前置請求
* @data 數據對象
*/
function (remainingRequest, precedingRequest, data) {
// some code
};其中 data 參數，可以用於數據傳遞。即在 pitch 函數中往 data 對象上添加數據，之後在 normal 函數中通過 this.data 的方式讀取已添加的數據。而 remainingRequest 和 precedingRequest 參數到底是什麼？這裏我們先來更新一下 a-loader.js 文件：
function aLoader(content, map, meta) {
// 省略部分代碼
}
aLoader.pitch = function (remainingRequest, precedingRequest, data) {
console.log("開始執行aLoader Pitching Loader");
console.log(remainingRequest, precedingRequest, data)
};
module.exports = aLoader;在以上代碼中，我們爲 aLoader 函數增加了一個 pitch 屬性並設置它的值爲一個函數對象。在函數體中，我們輸出了該函數所接收的參數。接着，我們以同樣的方式更新 b-loader.js 和 c-loader.js 文件：
b-loader.js
function bLoader(content, map, meta) {
// 省略部分代碼
}
bLoader.pitch = function (remainingRequest, precedingRequest, data) {
console.log("開始執行bLoader Pitching Loader");
console.log(remainingRequest, precedingRequest, data);
};
module.exports = bLoader;c-loader.js
function cLoader(content, map, meta) {
// 省略部分代碼
}
cLoader.pitch = function (remainingRequest, precedingRequest, data) {
console.log("開始執行cLoader Pitching Loader");
console.log(remainingRequest, precedingRequest, data);
};
module.exports = cLoader;當所有文件都更新完成後，我們在 webpack-loader-demo 項目的根目錄再次執行 npx webpack 命令後，就會輸出相應的信息。這裏我們以 b-loader.js 的 pitch 函數的輸出結果爲例，來分析一下 remainingRequest 和 precedingRequest 參數的輸出結果：
/Users/fer/webpack-loader-demo/loaders/c-loader.js!/Users/fer/webpack-loader-demo/src/data.txt #剩餘請求
/Users/fer/webpack-loader-demo/loaders/a-loader.js #前置請求
{} #空的數據對象除了以上的輸出信息之外，我們還可以很清楚的看到 Pitching Loader 和 Normal Loader 的執行順序：
開始執行aLoader Pitching Loader
...
開始執行bLoader Pitching Loader
...
開始執行cLoader Pitching Loader
...
開始執行cLoader Normal Loader
開始執行bLoader Normal Loader
開始執行aLoader Normal Loader很明顯對於我們的示例來說，Pitching Loader 的執行順序是 從左到右，而 Normal Loader 的執行順序是 從右到左。具體的執行過程如下圖所示：
提示：Webpack 內部會使用 loader-runner 這個庫來運行已配置的 loaders。
看到這裏有的小夥伴可能會有疑問，Pitching Loader 除了可以提前運行之外，還有什麼作用呢？其實當某個 Pitching Loader 返回非 undefined 值時，就會實現熔斷效果。這裏我們更新一下 bLoader.pitch 方法，讓它返回 "bLoader Pitching Loader->" 字符串：
bLoader.pitch = function (remainingRequest, precedingRequest, data) {
console.log("開始執行bLoader Pitching Loader");
return "bLoader Pitching Loader->";
};當更新完 bLoader.pitch 方法，我們再次執行 npx webpack 命令之後，控制檯會輸出以下內容：
開始執行aLoader Pitching Loader
開始執行bLoader Pitching Loader
開始執行aLoader Normal Loader
asset bundle.js 4.53 KiB [compared for emit] (name: main)
runtime modules 937 bytes 4 modules
...由以上輸出結果可知，當 bLoader.pitch 方法返回非 undefined 值時，跳過了剩下的 loader。具體執行流程如下圖所示：
提示：Webpack 內部會使用 loader-runner 這個庫來運行已配置的 loaders。
之後，我們在瀏覽器中再次打開 dist/index.html 文件。此時，在頁面上你將看到以下信息：
Webpack Loader 示例
bLoader Pitching Loader->aLoader]介紹完 Normal Loader 和 Pitching Loader 的相關知識，接下來我們來分析一下 Loader 是如何被運行的。
三、Loader 是如何被運行的？
要搞清楚 Loader 是如何被運行的，我們可以藉助斷點調試工具來找出 Loader 的運行入口。這裏我們以大家熟悉的 Visual Studio Code 爲例，來介紹如何配置斷點調試環境：
當你按照上述步驟操作之後，在當前項目（webpack-loader-demo）下，會自動創建 .vscode 目錄並在該目錄下自動生成一個 launch.json 文件。接着，我們複製以下內容直接替換 launch.json 中的原始內容。
{
"version": "0.2.0",
"configurations": [{
"type": "node",
"request": "launch",
"name": "Webpack Debug",
"cwd": "${workspaceFolder}",
"runtimeExecutable": "npm",
"runtimeArgs": ["run", "debug"],
"port": 5858
}]
}利用以上配置信息，我們創建了一個 Webpack Debug 的調試任務。當運行該任務的時候，會在當前工作目錄下執行 npm run debug 命令。因此，接下來我們需要在 package.json 文件中增加 debug 命令，具體內容如下所示：
// package.json
{
"scripts": {
"debug": "node --inspect=5858 ./node_modules/.bin/webpack"
},
}做好上述的準備之後，我們就可以在 a-loader 的 pitch 函數中添加一個斷點。對應的調用堆棧如下所示：
通過觀察以上的調用堆棧信息，我們可以看到調用 runLoaders 方法，該方法是來自於 loader-runner 模塊。所以要搞清楚 Loader 是如何被運行的，我們就需要分析 runLoaders 方法。下面我們來開始分析項目中使用的 loader-runner 模塊，它的版本是 4.2.0。其中 runLoaders 方法被定義在 lib/LoaderRunner.js 文件中：
// loader-runner/lib/LoaderRunner.js
exports.runLoaders = function runLoaders(options, callback) {
// read options
var resource = options.resource || "";
var loaders = options.loaders || [];
var loaderContext = options.context || {}; // Loader上下文對象
var processResource = options.processResource || ((readResource, context,
resource, callback) => {
context.addDependency(resource);
readResource(resource, callback);
}).bind(null, options.readResource || readFile);
// prepare loader objects
loaders = loaders.map(createLoaderObject);
loaderContext.context = contextDirectory;
loaderContext.loaderIndex = 0;
loaderContext.loaders = loaders;
// 省略大部分代碼
var processOptions = {
resourceBuffer: null,
processResource: processResource
};
// 迭代PitchingLoaders
iteratePitchingLoaders(processOptions, loaderContext, function(err, result) {
// ...
});
};由以上代碼可知，在 runLoaders 函數中，會先從 options 配置對象上獲取 loaders 信息，然後調用 createLoaderObject 函數創建 Loader 對象，調用該方法後會返回包含 normal、pitch、raw 和 data 等屬性的對象。目前該對象的大多數屬性值都爲 null，在後續的處理流程中，就會填充相應的屬性值。
// loader-runner/lib/LoaderRunner.js
function createLoaderObject(loader) {
var obj = {
path: null,
query: null,
fragment: null,
options: null,
ident: null,
normal: null,
pitch: null,
raw: null,
data: null,
pitchExecuted: false,
normalExecuted: false
};
// 省略部分代碼
obj.request = loader;
if(Object.preventExtensions) {
Object.preventExtensions(obj);
}
return obj;
}在創建完 Loader 對象及初始化 loaderContext 對象之後，就會調用 iteratePitchingLoaders 函數開始迭代 Pitching Loader。爲了讓大家對後續的處理流程有一個大致的瞭解，在看具體代碼前，我們再來回顧一下前面運行 txt loaders 的調用堆棧：
與之對應 runLoaders 函數的 options 對象結構如下所示：
基於上述的調用堆棧和相關的源碼，阿寶哥也畫了一張相應的流程圖：
看完上面的流程圖和調用堆棧圖，接下來我們來分析一下流程圖中相關函數的核心代碼。這裏我們先來分析 iteratePitchingLoaders：
// loader-runner/lib/LoaderRunner.js
function iteratePitchingLoaders(options, loaderContext, callback) {
// abort after last loader
if(loaderContext.loaderIndex >= loaderContext.loaders.length)
// 在processResource函數內，會調用iterateNormalLoaders函數
// 開始執行normal loader
return processResource(options, loaderContext, callback);
// 首次執行時，loaderContext.loaderIndex的值爲0
var currentLoaderObject = loaderContext.loaders[loaderContext.loaderIndex];
// 如果當前loader對象的pitch函數已經被執行過了，則執行下一個loader的pitch函數
if(currentLoaderObject.pitchExecuted) {
loaderContext.loaderIndex++;
return iteratePitchingLoaders(options, loaderContext, callback);
}
// 加載loader模塊
loadLoader(currentLoaderObject, function(err) {
if(err) {
loaderContext.cacheable(false);
return callback(err);
}
// 獲取當前loader對象上的pitch函數
var fn = currentLoaderObject.pitch;
// 標識loader對象已經被iteratePitchingLoaders函數處理過
currentLoaderObject.pitchExecuted = true;
if(!fn) return iteratePitchingLoaders(options, loaderContext, callback);
// 開始執行pitch函數
runSyncOrAsync(fn,loaderContext, ...);
// 省略部分代碼
});
}在 iteratePitchingLoaders 函數內部，會從最左邊的 loader 對象開始處理，然後調用 loadLoader 函數開始加載 loader 模塊。在 loadLoader 函數內部，會根據 loader 的類型，使用不同的加載方式。對於我們當前的項目來說，會通過 require(loader.path) 的方式來加載 loader 模塊。具體的代碼如下所示：
// loader-runner/lib/loadLoader.js
module.exports = function loadLoader(loader, callback) {
if(loader.type === "module") {
try {
if(url === undefined) url = require("url");
var loaderUrl = url.pathToFileURL(loader.path);
var modulePromise = eval("import(" + JSON.stringify(loaderUrl.toString()) + ")");
modulePromise.then(function(module) {
handleResult(loader, module, callback);
}, callback);
return;
} catch(e) {
callback(e);
}
} else {
try {
var module = require(loader.path);
} catch(e) {
// 省略相關代碼
}
// 處理已加載的模塊
return handleResult(loader, module, callback);
}
};不管使用哪種加載方式，在成功加載 loader 模塊之後，都會調用 handleResult 函數來處理已加載的模塊。該函數的作用是，獲取模塊中的導出函數及該函數上 pitch 和 raw 屬性的值並賦值給對應 loader 對象的相應屬性：
// loader-runner/lib/loadLoader.js
function handleResult(loader, module, callback) {
if(typeof module !== "function" && typeof module !== "object") {
return callback(new LoaderLoadingError(
"Module '" + loader.path + "' is not a loader (export function or es6 module)"
));
}
loader.normal = typeof module === "function" ? module : module.default;
loader.pitch = module.pitch;
loader.raw = module.raw;
if(typeof loader.normal !== "function" && typeof loader.pitch !== "function") {
return callback(new LoaderLoadingError(
"Module '" + loader.path + "' is not a loader (must have normal or pitch function)"
));
}
callback();
}在處理完已加載的 loader 模塊之後，就會繼續調用傳入的 callback 回調函數。在該回調函數內，會先在當前的 loader 對象上獲取 pitch 函數，然後調用 runSyncOrAsync 函數來執行 pitch 函數。對於我們的項目來說，就會開始執行 aLoader.pitch 函數。
看到這裏的小夥伴，應該已經知道 loader 模塊是如何被加載的及 loader 模塊中定義的 pitch 函數是如何被運行的。由於篇幅有限，阿寶哥就不再詳細展開介紹 loader-runner 模塊中其他函數。接下來，我們將通過幾個問題來繼續分析 loader-runner 模塊所提供的功能。
四、Pitching Loader 的熔斷機制是如何實現的？
// loader-runner/lib/LoaderRunner.js
function iteratePitchingLoaders(options, loaderContext, callback) {
// 省略部分代碼
loadLoader(currentLoaderObject, function(err) {
var fn = currentLoaderObject.pitch;
// 標識當前loader已經被處理過
currentLoaderObject.pitchExecuted = true;
// 若當前loader對象上未定義pitch函數，則處理下一個loader對象
if(!fn) return iteratePitchingLoaders(options, loaderContext, callback);
// 執行loader模塊中定義的pitch函數
runSyncOrAsync(
fn,
loaderContext, [loaderContext.remainingRequest,
loaderContext.previousRequest, currentLoaderObject.data = {}],
function(err) {
if(err) return callback(err);
var args = Array.prototype.slice.call(arguments, 1);
var hasArg = args.some(function(value) {
return value !== undefined;
});
if(hasArg) {
loaderContext.loaderIndex--;
iterateNormalLoaders(options, loaderContext, args, callback);
} else {
iteratePitchingLoaders(options, loaderContext, callback);
}
}
);
});
}在以上代碼中，runSyncOrAsync 函數的回調函數內部，會根據當前 loader 對象 pitch 函數的返回值是否爲 undefined 來執行不同的處理邏輯。如果 pitch 函數返回了非 undefined 的值，則會出現熔斷。即跳過後續的執行流程，開始執行上一個 loader 對象上的 normal loader 函數。具體的實現方式也很簡單，就是 loaderIndex 的值減 1，然後調用 iterateNormalLoaders 函數來實現。而如果 pitch 函數返回 undefined，則繼續調用 iteratePitchingLoaders 函數來處理下一個未處理 loader 對象。
五、Normal Loader 函數是如何被運行的？
// loader-runner/lib/LoaderRunner.js
function iterateNormalLoaders(options, loaderContext, args, callback) {
if(loaderContext.loaderIndex < 0)
return callback(null, args);
var currentLoaderObject = loaderContext.loaders[loaderContext.loaderIndex];
// normal loader的執行順序是從右到左
if(currentLoaderObject.normalExecuted) {
loaderContext.loaderIndex--;
return iterateNormalLoaders(options, loaderContext, args, callback);
}
// 獲取當前loader對象上的normal函數
var fn = currentLoaderObject.normal;
// 標識loader對象已經被iterateNormalLoaders函數處理過
currentLoaderObject.normalExecuted = true;
if(!fn) { // 當前loader對象未定義normal函數，則繼續處理前一個loader對象
return iterateNormalLoaders(options, loaderContext, args, callback);
}
convertArgs(args, currentLoaderObject.raw);
runSyncOrAsync(fn, loaderContext, args, function(err) {
if(err) return callback(err);
var args = Array.prototype.slice.call(arguments, 1);
iterateNormalLoaders(options, loaderContext, args, callback);
});
}由以上代碼可知，在 loader-runner 模塊內部會通過調用 iterateNormalLoaders 函數，來執行已加載 loader 對象上的 normal loader 函數。與 iteratePitchingLoaders 函數一樣，在 iterateNormalLoaders 函數內部也是通過調用 runSyncOrAsync 函數來執行 fn 函數。不過在調用 normal loader 函數前，會先調用 convertArgs 函數對參數進行處理。
convertArgs 函數會根據 raw 屬性來對 args[0]（文件的內容）進行處理，該函數的具體實現如下所示：
// loader-runner/lib/LoaderRunner.js
function convertArgs(args, raw) {
if(!raw && Buffer.isBuffer(args[0]))
args[0] = utf8BufferToString(args[0]);
else if(raw && typeof args[0] === "string")
args[0] = Buffer.from(args[0], "utf-8");
}
// 把buffer對象轉換爲utf-8格式的字符串
function utf8BufferToString(buf) {
var str = buf.toString("utf-8");
if(str.charCodeAt(0) === 0xFEFF) {
return str.substr(1);
} else {
return str;
}
}相信看完 convertArgs 函數的相關代碼之後，你對 raw 屬性的作用有了更深刻的瞭解。
六、Loader 函數體中的 this.callback 和 this.async 方法是哪裏來的？
Loader 可以分爲同步 Loader 和異步 Loader，對於同步 Loader 來說，我們可以通過 return 語句或 this.callback 的方式來同步地返回轉換後的結果。只是相比 return 語句，this.callback 方法則更靈活，因爲它允許傳遞多個參數。
sync-loader.js
module.exports = function(source) {
return source + "-simple";
};sync-loader-with-multiple-results.js
module.exports = function (source, map, meta) {
this.callback(null, source + "-simple", map, meta);
return; // 當調用 callback() 函數時，總是返回 undefined
};需要注意的是 this.callback 方法支持 4 個參數，每個參數的具體作用如下所示：
this.callback(
err: Error | null, // 錯誤信息
content: string | Buffer, // content信息
sourceMap?: SourceMap, // sourceMap
meta?: any // 會被 webpack 忽略，可以是任何東西
);而對於異步 loader，我們需要調用 this.async 方法來獲取 callback 函數：
async-loader.js
module.exports = function(source) {
var callback = this.async();
setTimeout(function() {
callback(null, source + "-async-simple");
}, 50);
};那麼以上示例中，this.callback 和 this.async 方法是哪裏來的呢？帶着這個問題，我們來從 loader-runner 模塊的源碼中，一探究竟。
this.async
// loader-runner/lib/LoaderRunner.js
function runSyncOrAsync(fn, context, args, callback) {
var isSync = true; // 默認是同步類型
var isDone = false; // 是否已完成
var isError = false; // internal error
var reportedError = false;
context.async = function async() {
if(isDone) {
if(reportedError) return; // ignore
throw new Error("async(): The callback was already called.");
}
isSync = false;
return innerCallback;
};
}在前面我們已經介紹過 runSyncOrAsync 函數的作用，該函數用於執行 Loader 模塊中設置的 Normal Loader 或 Pitching Loader 函數。在 runSyncOrAsync 函數內部，最終會通過 fn.apply(context, args) 的方式調用 Loader 函數。即會通過 apply 方法設置 Loader 函數的執行上下文。
此外，由以上代碼可知，當調用 this.async 方法之後，會先設置 isSync 的值爲 false，然後返回 innerCallback 函數。其實該函數與 this.callback 都是指向同一個函數。
this.callback
// loader-runner/lib/LoaderRunner.js
function runSyncOrAsync(fn, context, args, callback) {
// 省略部分代碼
var innerCallback = context.callback = function() {
if(isDone) {
if(reportedError) return; // ignore
throw new Error("callback(): The callback was already called.");
}
isDone = true;
isSync = false;
try {
callback.apply(null, arguments);
} catch(e) {
isError = true;
throw e;
}
};
}如果在 Loader 函數中，是通過 return 語句來返回處理結果的話，那麼 isSync 值仍爲 true，將會執行以下相應的處理邏輯：
// loader-runner/lib/LoaderRunner.js
function runSyncOrAsync(fn, context, args, callback) {
// 省略部分代碼
try {
var result = (function LOADER_EXECUTION() {
return fn.apply(context, args);
}());
if(isSync) { // 使用return語句返回處理結果
isDone = true;
if(result === undefined)
return callback();
if(result && typeof result === "object" && typeof result.then === "function") {
return result.then(function(r) {
callback(null, r);
}, callback);
}
return callback(null, result);
}
} catch(e) {
// 省略異常處理代碼
}
}通過觀察以上代碼，我們可以知道在 Loader 函數中，可以使用 return 語句直接返回 Promise 對象，比如這種方式：
module.exports = function(source) {
return Promise.resolve(source + "-promise-simple");
};現在我們已經知道 Loader 是如何返回數據，那麼 Loader 最終返回的結果是如何被處理的的呢？下面我們來簡單介紹一下。
七、Loader 最終的返回結果是如何被處理的？
// webpack/lib/NormalModule.js（Webpack 版本：5.45.1）
build(options, compilation, resolver, fs, callback) {
// 省略部分代碼
return this.doBuild(options, compilation, resolver, fs, err => {
// if we have an error mark module as failed and exit
if (err) {
this.markModuleAsErrored(err);
this._initBuildHash(compilation);
return callback();
}
// 省略部分代碼
let result;
try {
result = this.parser.parse(this._ast || this._source.source(), {
current: this,
module: this,
compilation: compilation,
options: options
});
} catch (e) {
handleParseError(e);
return;
}
handleParseResult(result);
});
}由以上代碼可知，在 this.doBuild 方法的回調函數中，會使用 JavascriptParser 解析器對返回的內容進行解析操作，而底層是通過 acorn 這個第三方庫來實現 JavaScript 代碼的解析。而解析後的結果，會繼續調用 handleParseResult 函數進行進一步處理。這裏阿寶哥就不展開介紹了，感興趣的小夥伴可以自行閱讀一下相關源碼。
八、爲什麼要把 content 賦值給 module.exports 屬性呢？
最後我們來回答前面留下的問題 —— 在 a-loader.js 模塊中，爲什麼要把 content 賦值給 module.exports 屬性呢？要回答這個問題，我們將從 Webpack 生成的 bundle.js 文件（已刪除註釋信息）中找到該問題的答案：
__webpack_modules__
var __webpack_modules__ = ({
"./src/data.txt": ((module)=>{
eval("module.exports = '大家好，我是阿寶哥[cLoader->bLoader->aLoader]'\n\n//#
sourceURL=webpack://webpack-loader-demo/./src/data.txt?");
}),
"./src/index.js":((__unused_webpack_module, __webpack_exports__, __webpack_require__) => {
eval("__webpack_require__.r(__webpack_exports__);\n/* harmony import */ var
_data_txt__WEBPACK_IMPORTED_MODULE_0__ = __webpack_require__(/*! ./data.txt */ \"./src/data.txt\");...
);
})
});__webpack_require__
// The module cache
var __webpack_module_cache__ = {};
// The require function
function __webpack_require__(moduleId) {
// Check if module is in cache
var cachedModule = __webpack_module_cache__[moduleId];
if (cachedModule !== undefined) {
return cachedModule.exports;
}
// Create a new module (and put it into the cache)
var module = __webpack_module_cache__[moduleId] = {
exports: {}
};
// Execute the module function
__webpack_modules__[moduleId](module, module.exports, __webpack_require__);
// Return the exports of the module
return module.exports;
}在生成的 bundle.js 文件中，./src/index.js 對應的函數內部，會通過調用 __webpack_require__ 函數來導入 ./src/data.txt 路徑中的內容。而在 __webpack_require__ 函數內部會優先從緩存對象中獲取 moduleId 對應的模塊，若該模塊已存在，就會返回該模塊對象上 exports 屬性的值。如果緩存對象中不存在 moduleId 對應的模塊，則會創建一個包含 exports 屬性的 module 對象，然後會根據 moduleId 從 __webpack_modules__ 對象中，獲取對應的函數並使用相應的參數進行調用，最終返回 module.exports 的值。所以在 a-loader.js 文件中，把 content 賦值給 module.exports 屬性的目的是爲了導出相應的內容。
九、總結
本文介紹了 Webpack Loader 的本質、Normal Loader 和 Pitching Loader 的定義和使用及 Loader 是如何被運行的等相關內容，希望閱讀完本文之後，你對 Webpack Loader 機制能有更深刻的理解。文中阿寶哥只介紹了 loader-runner 模塊，其實 loader-utils（Loader 工具庫）和 schema-utils（Loader Options 驗證庫）這兩個模塊也與 Loader 息息相關。在編寫 Loader 的時候，你可能就會使用到它們。如果你對如何編寫一個 Loader 感興趣的話，可以閱讀 writing-a-loader 這個文檔或掘金上 手把手教你擼一個 Webpack Loader 這篇文章。
十、參考資源
-
Webpack 官網
-
Github — loader-runner
本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/2v1uhw2j7yKsb1U5KE2qJA