1. 程式人生 > >.32-淺析webpack源碼之doResolve事件流(4)

.32-淺析webpack源碼之doResolve事件流(4)

define 區別 打開 滿足 work 流程圖 mod adf after

  流程圖如下:技術分享圖片

重回DescriptionFilePlugin

  上一節最後進入relative事件流,註入地點如下:

// relative
plugins.push(new DescriptionFilePlugin("relative", descriptionFiles, "described-relative"));
plugins.push(new NextPlugin("after-relative", "described-relative"));

  這似曾相識的感覺,這不就是解析package.json的插件麽,又調用了一次。

  但是有一點點微妙的不同,第一次調用該插件時,request對象如下所示:

/*
    {
        context: { issuer: ‘‘, compiler: undefined },
        path: ‘d:\\workspace\\doc‘,
        request: ‘./input.js‘,
        query: ‘‘,
        module: false,
        directory: false,
        file: false
    }
*/

  在經過幾個插件的洗禮後,變成了下面這樣:

/*
    {
        context: { issuer: ‘‘, compiler: undefined },
        path: ‘d:\\workspace\\doc\\input.js‘,
        request: undefined,
        query: ‘‘,
        module: false,
        directory: false,
        file: false,
        descriptionFilePath: ‘d:\\workspace\\doc\\package.json‘,
        descriptionFileData: {*package.json*},
        descriptionFileRoot: ‘d:\\workspace\\doc‘,
        relativePath: ‘./input.js‘,
        __innerRequest_request: ‘./input.js‘,
        __innerRequest_relativePath: ‘.‘,
        __innerRequest: ‘./input.js‘
    }
*/

  主要變化就是path由文件目錄變成了文件路徑,request被置為undefined。

  由於插件源碼之前跑過,但是有一個不同點,就是forEachBail中的路徑獲取。

var descriptionFilePath = resolver.join(directory, filename);

  這裏的directory就是上面的path,filename沒有變,就是package.json。

  之前看源碼分析過,這裏是獲取對應directory的Map值,然後再獲取Map中鍵為filename的路徑字符串,由於參數更改,所以這裏內部生成了一個新的Map保存新directory路徑。

  那麽問題來了,再來看看處理路徑的方法:

module.exports = function join(path, request) {
    /*
        path => d:\\workspace\\doc\\input.js
        request => package.json
    */
    if (!request) return normalize(path);
    if (absoluteWinRegExp.test(request)) return normalize(request.replace(/\//g, "\\"));
    if (absoluteNixRegExp.test(request)) return normalize(request);
    if (path == "/") return normalize(path + request);
    // 依然滿足絕對路徑的正則校驗
    // 拼接後變成了d:\workspace\doc\input.js\package.json
    if (absoluteWinRegExp.test(path)) return normalize(path.replace(/\//g, "\\") + "\\" + request.replace(/\//g, "\\"));
    if (absoluteNixRegExp.test(path)) return normalize(path + "/" + request);
    return normalize(path + "/" + request);
};

  完全是一個非法路徑,所以以下代碼會直接報錯:

if (resolver.fileSystem.readJson) {
    // 非法路徑
    resolver.fileSystem.readJson(descriptionFilePath, function(err, content) {
        if (err) {
            /*
                { 
                    Error: ENOENT: no such file or directory, open ‘d:\workspace\doc\input.js\package.json‘
                    errno: -4058,
                    code: ‘ENOENT‘,
                    syscall: ‘open‘,
                    path: ‘d:\\workspace\\doc\\input.js\\package.json‘ 
                }
            */
            // 進入這個if分支
            if (typeof err.code !== "undefined") return callback();
            return onJson(err);
        }
        onJson(null, content);
    });
}

  註意,這裏調用的是無參callback,進入的分支也不一樣:

function(err, result) {
    if (err) return callback(err);
    // 之前讀取package.json成功進入這個分支
    if (result) {
        return callback(null, result);
    }
    // 這次是這裏 
    else {
        directory = cdUp(directory);
        if (!directory) {
            return callback();
        } else {
            return findDescriptionFile();
        }
    }
}

  這個奇妙的cdUp函數名就很靈性了,看看是什麽鬼。

// directory => d:\workspace\doc\input.js
function cdUp(directory) {
    if (directory === "/") return null;
    // 從後往前搜索路徑字符
    var i = directory.lastIndexOf("/"),
        j = directory.lastIndexOf("\\");
    var p = i < 0 ? j : j < 0 ? i : i < j ? j : i;
    if (p < 0) return null;
    // 切割字符串
    // 返回d:\workspace\doc
    return directory.substr(0, p || 1);
}

  其實也沒啥,三元超級表達式配合返回的切割就是獲取對應的目錄。

  獲取到了對應的目錄,再次調用了findDescriptionFile函數,即讀取配置文件的IIFE。這一次directory變成了目錄,跟第一次一樣,走的流程也一樣了。

described-relative => FileKindPlugin

  最後其實什麽都沒有做,觸發了下一個事件流described-relative,這個插件比較簡單:

FileKindPlugin.prototype.apply = function(resolver) {
    var target = this.target;
    resolver.plugin(this.source, function(request, callback) {
        // false
        if (request.directory) return callback();
        var obj = Object.assign({}, request);
        delete obj.directory;
        resolver.doResolve(target, obj, null, callback);
    });
};

  由於之前在ParsePlugin解析過文件屬性,判斷為非文件目錄,所以會直接調用doResolve進行下一個事件流。

  說實話,我有點怕這裏調用callback,因為又要思考,這到底是哪個callback???

raw-file => TryNextPlugin

  該事件流註入如下:

// raw-file
// 默認為false
if (!enforceExtension)
    plugins.push(new TryNextPlugin("raw-file", "no extension", "file"));
plugins.push(new ConcordExtensionsPlugin("raw-file", {}, "file"));
extensions.forEach(function(item) {
    plugins.push(new AppendPlugin("raw-file", item, "file"));
});

  看似這麽多插件,實際上在第一個插件就直接跳過了。

TryNextPlugin.prototype.apply = function(resolver) {
    var target = this.target;
    var message = this.message;
    resolver.plugin(this.source, function(request, callback) {
        // 給出message直接觸發target事件流
        resolver.doResolve(target, request, message, callback);
    });
};

  如果不設置exforceExtension屬性為true,是會跳過raw-file事件流,直接進入file事件流。

file

  這個地方就基本快到尾聲了,註入地點如下:

// file
// 一模一樣的調用
alias.forEach(function(item) {
    plugins.push(new AliasPlugin("file", item, "resolve"));
});
plugins.push(new ConcordModulesPlugin("file", {}, "resolve"));
aliasFields.forEach(function(item) {
    plugins.push(new AliasFieldPlugin("file", item, "resolve"));
});
// 未定義默認為true
if (symlinks)
    plugins.push(new SymlinkPlugin("file", "relative"));
plugins.push(new FileExistsPlugin("file", "existing-file"));

  這前幾個插件又是一模一樣的,這次連參數都一樣,所以懶得看了,直接跳。

SymlinkPlugin

  這個插件是新的,內部實現如下:

SymlinkPlugin.prototype.apply = function(resolver) {
    var target = this.target;
    resolver.plugin(this.source, function(request, callback) {
        var _this = this;
        var fs = _this.fileSystem;
        // 切割路徑
        var pathsResult = getPaths(request.path);
        var pathSeqments = pathsResult.seqments;
        var paths = pathsResult.paths;

        var containsSymlink = false;
        // 新方法
        // 其實只是叠代函數多了一個索引參數
        forEachBail.withIndex(paths, function(path, idx, callback) {
            // 異步讀取鏈接
            // 傻逼一樣的方法 全部失敗
            fs.readlink(path, function(err, result) {
                if (!err && result) {
                    pathSeqments[idx] = result;
                    containsSymlink = true;
                    // Shortcut when absolute symlink found
                    if (/^(\/|[a-zA-z]:($|\\))/.test(result))
                        return callback(null, idx);
                }
                callback();
            });
        }, function(err, idx) {
            // 直接返回
            if (!containsSymlink) return callback();
            var resultSeqments = typeof idx === "number" ? pathSeqments.slice(0, idx + 1) : pathSeqments.slice();
            var result = resultSeqments.reverse().reduce(function(a, b) {
                return _this.join(a, b);
            });
            var obj = Object.assign({}, request, {
                path: result
            });
            resolver.doResolve(target, obj, "resolved symlink to " + result, callback);
        });
    });
};

  先看一下路徑切割:

module.exports = function getPaths(path) {
    var parts = path.split(/(.*?[\\\/]+)/);
    var paths = [path];
    var seqments = [parts[parts.length - 1]];
    var part = parts[parts.length - 1];
    path = path.substr(0, path.length - part.length - 1);
    paths.push(path);
    /*
        paths => [ ‘d:\\workspace\\doc\\input.js‘,‘input.js‘ ]
        parts => [ ‘‘, ‘d:\\‘, ‘‘, ‘workspace\\‘, ‘‘, ‘doc\\‘, ‘input.js‘ ]
        path => ‘input.js‘
    */
    for (var i = parts.length - 2; i > 2; i -= 2) {
        part = parts[i];
        // 切割目錄
        path = path.substr(0, path.length - part.length) || "/";
        paths.push(path);
        // 獲取對應文件夾/文件名
        seqments.push(part.substr(0, part.length - 1));
    }
    part = parts[1];
    seqments.push(part.length > 1 ? part.substr(0, part.length - 1) : part);
    /*
        {
            paths: [ ‘d:\\workspace\\doc\\input.js‘,‘d:\\workspace\\doc‘,‘d:\\workspace‘,‘d:‘ ]
            seqments: [ ‘input.js‘, ‘doc‘, ‘workspace‘ ]
        }
    */
    return {
        paths: paths,
        seqments: seqments
    };
};

  切割了文件目錄的文件夾名稱以及對應的目錄,最後返回一個對象。

  接下來調用了一個文件讀取方法readlink,剛開始我以為跟readFIle一樣根據路徑讀取文件內容,後來發現所有傳進去的路徑全部報錯。

  也就是一個都沒有讀取到,直接callback返回了。

  這是什麽傻逼方法?因為沒FQ,百度搜索都是垃圾內容,只能上官網看原文:http://man7.org/linux/man-pages/man2/readlink.2.html

  值得註意的只有一句話:readlink, readlinkat - read value of a symbolic link

  symbolic link?這是啥,查了半天,原來是符號鏈接,屬於一種類似於快捷方式的東西,可以理解為文件指針。

  廢了我很大的力氣,我才實現這個API的作用。

  這裏假設我要在D盤建立一個符號鏈接,目標是c盤的Windows文件夾,打開CMD,輸入以下指令:

mklink /D D:\symbolic C:\Windows

  會彈出一個提示:為*** <<===>> *** 創建的符號鏈接,這時候打開D盤,會看到一個類似於快捷方式的文件夾,打開後能看到Windows的內容。

  看起來跟快捷方式一樣,實際上還是有區別的,最直觀的就是路徑上,符號鏈接打開後路徑仍然是當前文件夾,但是快捷方式會跳到引用的地方,也就是:

  技術分享圖片

  打開符號鏈接,看起來好像復制了Windows所有內容到鏈接裏一樣,快捷方式都懂的,就不演示了。

  回到該方法,如果傳入符號鏈接,上述例子會返回:C:\Windows,也就是對應的路徑。

  一句話就是,這個對我這種程度的使用者基本上沒有卵用。

  這節先這樣。

.32-淺析webpack源碼之doResolve事件流(4)