.32-浅析webpack源码之doResolve事件流(4)

时间:2022-10-26 09:07:23

  流程图如下:.32-浅析webpack源码之doResolve事件流(4)

重回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返回了。

  这是什么傻逼方法?因为没*,百度搜索都是垃圾内容,只能上官网看原文: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的内容。

  看起来跟快捷方式一样,实际上还是有区别的,最直观的就是路径上,符号链接打开后路径仍然是当前文件夹,但是快捷方式会跳到引用的地方,也就是:

  .32-浅析webpack源码之doResolve事件流(4)

  打开符号链接,看起来好像复制了Windows所有内容到链接里一样,快捷方式都懂的,就不演示了。

  回到该方法,如果传入符号链接,上述例子会返回:C:\Windows,也就是对应的路径。

  一句话就是,这个对我这种程度的使用者基本上没有卵用。

  这节先这样。

.32-浅析webpack源码之doResolve事件流(4)的更多相关文章

  1. &period;30-浅析webpack源码之doResolve事件流&lpar;1&rpar;

    这里所有的插件都对应着一个小功能,画个图整理下目前流程: 上节是从ParsePlugin中出来,对'./input.js'入口文件的路径做了处理,返回如下: ParsePlugin.prototype ...

  2. &period;30-浅析webpack源码之doResolve事件流&lpar;2&rpar;

    这里所有的插件都对应着一个小功能,画个图整理下目前流程: 上节是从ParsePlugin中出来,对'./input.js'入口文件的路径做了处理,返回如下: ParsePlugin.prototype ...

  3. &period;29-浅析webpack源码之doResolve事件流&lpar;1&rpar;

    在上一节中,最后返回了一个resolver,本质上就是一个Resolver对象: resolver = new Resolver(fileSystem); 这个对象的构造函数非常简单,只是简单的继承了 ...

  4. &period;31-浅析webpack源码之doResolve事件流&lpar;2&rpar;

    放个流程图: 这里也放一下request对象内容,这节完事后如下(把vue-cli的package.json也复制过来了): /* { context: { issuer: '', compiler: ...

  5. &period;33-浅析webpack源码之doResolve事件流&lpar;5&rpar;

    file => FileExistsPlugin 这个事件流快接近尾声了,接下来是FileExistsPlugin,很奇怪的是在最后才来检验路径文件是否存在. 源码如下: FileExistsP ...

  6. &period;34-浅析webpack源码之事件流make&lpar;3&rpar;

    新年好呀~过个年光打游戏,function都写不顺溜了. 上一节的代码到这里了: // NormalModuleFactory的resolver事件流 this.plugin("resolv ...

  7. 浅析libuv源码-node事件轮询解析&lpar;3&rpar;

    好像博客有观众,那每一篇都画个图吧! 本节简图如下. 上一篇其实啥也没讲,不过node本身就是这么复杂,走流程就要走全套.就像曾经看webpack源码,读了300行代码最后就为了取package.js ...

  8. &period;27-浅析webpack源码之事件流make&lpar;2&rpar;

    上一节跑到了NormalModuleFactory模块,调用了原型方法create后,依次触发了before-rsolve.factory.resolver事件流,这节从resolver事件流开始讲. ...

  9. &period;17-浅析webpack源码之compile流程-入口函数run

    本节流程如图: 现在正式进入打包流程,起步方法为run: Compiler.prototype.run = (callback) => { const startTime = Date.now( ...

随机推荐

  1. Jquery 小技巧

    [每个程序员都会的35个jQuery的小技巧]收集的35个jQuery的小技巧/代码片段,可以帮你快速开发

  2. WPF 打印

    1. System.Windows.Controls.PrintDialog printDialog = new System.Windows.Controls.PrintDialog(); if ( ...

  3. wikioi 1203 判断浮点数是否相等

    /*======================================================================== 1203 判断浮点数是否相等 题目描述 Descr ...

  4. ASP&period;NET 去除所有HTML标记的方法

    using System.Text.RegularExpressions /// <summary> /// 去除HTML标记 /// </summary> /// <p ...

  5. 深度围观block:第三集

    深度围观block:第三集 发布于:2013-07-12 10:09阅读数:7804 本文是深度围观block的第三篇文章,也是最后一篇.希望读者阅读了之后,对block有更加深入的理解,同时也希望之 ...

  6. 用js动态的改变img标签里面的src属性实现图片的循环切换

    JS:根据循环切换的条件可以用 document.getElementById('').src=''设置, 或者jquery方法: $('#id').attr('src','图片名称’): 具体: i ...

  7. Linux 安装SVN服务器 (转)

    一. SVN 简介 Subversion(SVN) 是一个开源的版本控制系統, 也就是说 Subversion 管理着随时间改变的数据. 这些数据放置在一个*资料档案库 (repository) 中 ...

  8. xmlplus 组件设计系列之七 - 路由

    在浏览器端,对路由的理解一般是根据不同的 URL 完成页面的切换.在服务器端,则是根据不同的 URL 请求回馈相关的页面.在本章,我们讲述的是根据接收到的不同命令,路由组件呈现出不同的页面,这算是广义 ...

  9. 关于html&plus;ashx开发中几个问题的解决方法的感想和总结

    1.针对上篇文章中的服务端处理不敢苟同.仍然坚持使用反射,建立BaseHandler.ashx并在默认process方法中写上反射方法以及权限验证方法.针对具体的情况返回对应的值.服务端其他handl ...

  10. webpack配置之代码优化

    前面的话 前面介绍了webpack的基本配置,本文将详细介绍webpack中关于代码优化的配置 打包公共代码 CommonsChunkPlugin 插件,是一个可选的用于建立一个独立文件(又称作 ch ...