在上一节中,最后返回了一个resolver,本质上就是一个Resolver对象:

  1. resolver = new Resolver(fileSystem);

  这个对象的构造函数非常简单,只是简单的继承了Tapable,并接收了fileSystem参数:

  1. function Resolver(fileSystem) {
  2. Tapable.call(this);
  3. this.fileSystem = fileSystem;
  4. }
  5. module.exports = Resolver;

resolve

  而在make事件流中,调用的正是该类的原型方法resolve,现在可以进行看一眼了:

  1. /*
  2. context => { issuer: '', compiler: undefined }
  3. path => 'd:\\workspace\\doc'
  4. request => './input.js'
  5. callback => [Function]
  6. */
  7. Resolver.prototype.resolve = function resolve(context, path, request, callback) {
  8. if (arguments.length === 3) {
  9. throw new Error("Signature changed: context parameter added");
  10. }
  11. var resolver = this;
  12. // 包装参数
  13. var obj = {
  14. context: context,
  15. path: path,
  16. request: request
  17. };
  18.  
  19. var localMissing;
  20. var log;
  21. // message => resolve './input.js' in 'd:\\workspace\\doc'
  22. var message = "resolve '" + request + "' in '" + path + "'";
  23.  
  24. function writeLog(msg) {
  25. log.push(msg);
  26. }
  27.  
  28. function logAsString() {
  29. return log.join("\n");
  30. }
  31.  
  32. function onError(err, result) { /**/ }
  33.  
  34. function onResolve(err, result) { /**/ }
  35. // 这两个并不存在
  36. onResolve.missing = callback.missing;
  37. onResolve.stack = callback.stack;
  38. // 调用另一个原型方法
  39. return this.doResolve("resolve", obj, message, onResolve);
  40. };

  需要注意的是,该方法会在webpack编译期间被调用多次,这里的参数仅仅是第一次被调用时的。

doResolve

  简单的说,resolve方法将参数进行二次包装后,调用了另外一个原型方法doResolve,源码整理如下:

  1. /*
  2. type => 'resolve'
  3. request =>
  4. {
  5. context: { issuer: '', compiler: undefined },
  6. path: 'd:\\workspace\\doc',
  7. request: './input.js'
  8. }
  9. message => resolve './input.js' in 'd:\\workspace\\doc'
  10. callback => doResolve()
  11. */
  12. Resolver.prototype.doResolve = function doResolve(type, request, message, callback) {
  13. var resolver = this;
  14. // stackLine => resolve: (d:\workspace\doc) ./input.js
  15. var stackLine = type + ": (" + request.path + ") " +
  16. (request.request || "") + (request.query || "") +
  17. (request.directory ? " directory" : "") +
  18. (request.module ? " module" : "");
  19. var newStack = [stackLine];
  20. // 暂无
  21. if (callback.stack) { /**/ }
  22. // 没这个事件流
  23. resolver.applyPlugins("resolve-step", type, request);
  24. // before-resolve
  25. var beforePluginName = "before-" + type;
  26. // 检测是否存在对应的before事件流
  27. if (resolver.hasPlugins(beforePluginName)) { /**/ }
  28. // 走正常流程
  29. else {
  30. runNormal();
  31. }
  32. }

  由于callback的missing、stack属性均为undefined,所以会直接跳过那个if判断。

  而事件流resolve-step、before-resolve也不存在,所以会直接走最后的else,进入runNormal方法。

  这里全面描述一下doResolve,方法内部有5个函数,分别名为beforeInnerCallback、runNormal、innerCallback、runAfter、afterInnerCallback,所有的callback函数都负责包装对应事件流的回调函数。

  源码如下:

  1. // 先判断是否存在before-type事件流
  2. if (resolver.hasPlugins(beforePluginName)) {
  3. // 触发完调用回调
  4. resolver.applyPluginsAsyncSeriesBailResult1(beforePluginName, request, createInnerCallback(beforeInnerCallback, {
  5. log: callback.log,
  6. missing: callback.missing,
  7. stack: newStack
  8. }, message && ("before " + message), true));
  9. }
  10. // 不存在跳过直接触发type事件流
  11. else {
  12. runNormal();
  13. }
  14.  
  15. function beforeInnerCallback(err, result) {
  16. if (arguments.length > 0) {
  17. if (err) return callback(err);
  18. if (result) return callback(null, result);
  19. return callback();
  20. }
  21. // 这里进入下一阶段
  22. runNormal();
  23. }
  24.  
  25. // 触发type事件流
  26. function runNormal() {
  27. if (resolver.hasPlugins(type)) { /**/ } else {
  28. runAfter();
  29. }
  30. }
  31.  
  32. function innerCallback(err, result) { /**/ }
  33. // 触发after-type
  34. function runAfter() {
  35. var afterPluginName = "after-" + type;
  36. // 这里就是直接调用callback了
  37. if (resolver.hasPlugins(afterPluginName)) { /**/ } else {
  38. callback();
  39. }
  40. }
  41.  
  42. function afterInnerCallback(err, result) { /**/ }

  可以看到逻辑很简单,每一个事件流type存在3个类型:before-type、type、after-type,doResolve会尝试依次触发每一个阶段的事件流。

  在上面的例子中,因为不存在before-resolve事件流,所以会调用runNormal方法去触发resolve的事件流。

  如果存在,触发对应的事件流,并在回调函数中触发下一阶段的事件流。

  所以这里的调用就可以用一句话概括:尝试触发before-resolve、resolve、after-resolve事件流后,调用callback。

unsafeCache

  resolve事件流均来源于上一节第三部分注入的开头,如下:

  1. // resolve
  2. if (unsafeCache) {
  3. plugins.push(new UnsafeCachePlugin("resolve", cachePredicate, unsafeCache, cacheWithContext, "new-resolve"));
  4. plugins.push(new ParsePlugin("new-resolve", "parsed-resolve"));
  5. } else {
  6. plugins.push(new ParsePlugin("resolve", "parsed-resolve"));
  7. }

UnsafeCachePlugin

  这个unsafeCache虽然不知道是啥,但是一般不会去设置,默认情况下是true,因此进入UnsafeCachePlugin插件,构造函数如下:

  1. /*
  2. source => resolve
  3. filterPredicate => function(){return true}
  4. cache => {}
  5. withContext => false
  6. target => new-resolve
  7. */
  8. function UnsafeCachePlugin(source, filterPredicate, cache, withContext, target) {
  9. this.source = source;
  10. this.filterPredicate = filterPredicate;
  11. this.withContext = withContext;
  12. this.cache = cache || {};
  13. this.target = target;
  14. }

  基本上只是对传入参数的获取,直接看事件流的内容:

  1. function getCacheId(request, withContext) {
  2. // 直接用配置对象的字符串形式作为缓存对象key
  3. // 貌似vue源码的compile也是这样的
  4. return JSON.stringify({
  5. context: withContext ? request.context : "",
  6. path: request.path,
  7. query: request.query,
  8. request: request.request
  9. });
  10. }
  11. UnsafeCachePlugin.prototype.apply = function(resolver) {
  12. var filterPredicate = this.filterPredicate;
  13. var cache = this.cache;
  14. var target = this.target;
  15. var withContext = this.withContext;
  16. // 这里注入resolve事件流
  17. /*
  18. request =>
  19. {
  20. context: { issuer: '', compiler: undefined },
  21. path: 'd:\\workspace\\doc',
  22. request: './input.js'
  23. }
  24. callback => createInnerCallback(innerCallback,{...})
  25. */
  26. resolver.plugin(this.source, function(request, callback) {
  27. // 这里永远是true
  28. if (!filterPredicate(request)) return callback();
  29. // 尝试获取缓存
  30. var cacheId = getCacheId(request, withContext);
  31. var cacheEntry = cache[cacheId];
  32. if (cacheEntry) {
  33. return callback(null, cacheEntry);
  34. }
  35. // 这里再次调用了doResolve函数
  36. // target => new-resolve
  37. resolver.doResolve(target, request, null, createInnerCallback(function(err, result) {
  38. if (err) return callback(err);
  39. if (result) return callback(null, cache[cacheId] = result);
  40. callback();
  41. }, callback));
  42. });
  43. };

  这样就很明显了,resolve事件只是为了获取缓存,如果不存在缓存,就再次调用doResolve方法,这一次传入的type为new-resolve。

ParsePlugin

  new-resolve事件流并不存在before-xxx或者after-xxx的情况,所以直接看事件流本身。注入地点在UnsafeCachePlugin插件的后面。

  从上面的if/else可以看出,无论如何都会调用该插件,只是会根据unsafeCache的值来决定是否取缓存。

  这个插件内容比较简单暴力,简答过一下:

  1. // source => new-resolve
  2. // target => parsed-resolve
  3. function ParsePlugin(source, target) {
  4. this.source = source;
  5. this.target = target;
  6. }
  7. module.exports = ParsePlugin;
  8.  
  9. ParsePlugin.prototype.apply = function(resolver) {
  10. var target = this.target;
  11. resolver.plugin(this.source, function(request, callback) {
  12. // 解析
  13. var parsed = resolver.parse(request.request);
  14. // 合并对象
  15. var obj = Object.assign({}, request, parsed);
  16. if (request.query && !parsed.query) {
  17. obj.query = request.query;
  18. }
  19. if (parsed && callback.log) {
  20. if (parsed.module)
  21. callback.log("Parsed request is a module");
  22. if (parsed.directory)
  23. callback.log("Parsed request is a directory");
  24. }
  25. // 触发target的doResolve
  26. resolver.doResolve(target, obj, null, callback);
  27. });
  28. };

  基本上都是一个套路了,触发事件流,做点什么,然后最后调用doResolve触发下一轮。

  这里的核心就是parse方法,估计跟vue源码的parse差不多,比较麻烦,下一节再讲。

Resolver.prototype.parse

  这个parse方法超级简单,如下:

  1. Resolver.prototype.parse = function parse(identifier) {
  2. if (identifier === "") return null;
  3. var part = {
  4. request: "",
  5. query: "",
  6. module: false,
  7. directory: false,
  8. file: false
  9. };
  10. // 根据问号切割参数
  11. var idxQuery = identifier.indexOf("?");
  12. if (idxQuery === 0) {
  13. part.query = identifier;
  14. } else if (idxQuery > 0) {
  15. part.request = identifier.slice(0, idxQuery);
  16. part.query = identifier.slice(idxQuery);
  17. } else {
  18. part.request = identifier;
  19. }
  20. if (part.request) {
  21. // 判断是文件还是文件夹
  22. part.module = this.isModule(part.request);
  23. part.directory = this.isDirectory(part.request);
  24. // 去掉文件夹最后的斜杠
  25. if (part.directory) {
  26. part.request = part.request.substr(0, part.request.length - 1);
  27. }
  28. }
  29. return part;
  30. };
  31. /*
  32. 匹配以下内容开头的字符串
  33. 1 => .
  34. 2 => ./ or .\
  35. 3 => ..
  36. 4 => ../ or ..\
  37. 5 => /
  38. 6 => A-Z:/ or A-Z:\
  39. */
  40. var notModuleRegExp = /^\.$|^\.[\\\/]|^\.\.$|^\.\.[\/\\]|^\/|^[A-Z]:[\\\/]/i;
  41. Resolver.prototype.isModule = function isModule(path) {
  42. return !notModuleRegExp.test(path);
  43. };
  44. /*
  45. 匹配以\ or /结尾的字符串
  46. */
  47. var directoryRegExp = /[\/\\]$/i;
  48. Resolver.prototype.isDirectory = function isDirectory(path) {
  49. return directoryRegExp.test(path);
  50. };

  内容很简单,就做了2件事:

1、根据问号切割参数

2.、判断是文件还是文件夹

  最后返回了信息组成的对象。

.29-浅析webpack源码之Resolver.prototype.resolve的更多相关文章

  1. .30-浅析webpack源码之doResolve事件流(1)

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

  2. .34-浅析webpack源码之事件流make(3)

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

  3. .30-浅析webpack源码之doResolve事件流(2)

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

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

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

  5. .17-浅析webpack源码之compile流程-入口函数run

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

  6. .3-浅析webpack源码之预编译总览

    写在前面: 本来一开始想沿用之前vue源码的标题:webpack源码之***,但是这个工具比较巨大,所以为防止有人觉得我装逼跑来喷我(或者随时鸽),加上浅析二字,以示怂. 既然是浅析,那么案例就不必太 ...

  7. 从Webpack源码探究打包流程,萌新也能看懂~

    简介 上一篇讲述了如何理解tapable这个钩子机制,因为这个是webpack程序的灵魂.虽然钩子机制很灵活,而然却变成了我们读懂webpack道路上的阻碍.每当webpack运行起来的时候,我的心态 ...

  8. .13-浅析webpack源码之WatcherManager模块

    从模块流可以看出,这个NodeWatchFileSystem模块非常深,这里暂时不会深入到chokidar模块,有点太偏离本系列文章了,从WatcherManager开始讲解. 流程如图: 源码非常简 ...

  9. 浅析libuv源码-node事件轮询解析(3)

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

随机推荐

  1. 基于telegraf+influxdb+grafana进行postgresql数据库监控

    前言 随着公司postgresql数据库被广泛应用,尤其是最近多个项目在做性能测试的时候都是基于postgresql的数据库,为了确定性能瓶颈是否会出现在数据库中,数据库监控也被我推上了日程.在网上找 ...

  2. sp_tableoption

    设置用户定义表的选项值.sp_tableoption 可用于控制包含varchar(max).nvarchar(max).varbinary(max).xml.text.ntext 或 image 列 ...

  3. angular4.0如何引入外部插件2:declare方案

    前面有个<angular4.0如何引入外部插件1:import方案>,但是有局限,因为方案1需要用到@types这个东西. 但是并不是每一个插件都有@types,所以现在写个方案2. 拿引 ...

  4. 【Java框架型项目从入门到装逼】第八节 - 用EasyUI绘制主界面

    1.引入资源包 在上一节中,我们把基本的框架都搭好了,用了Spring,SPringMVC.这一节,我们先来画页面,前端框架采用EasyUI来实现. easyui是一种基于jQuery的用户界面插件集 ...

  5. python 常用算法

    算法就是为了解决某一个问题而采取的具体有效的操作步骤 算法的复杂度,表示代码的运行效率,用一个大写的O加括号来表示,比如O(1),O(n) 认为算法的复杂度是渐进的,即对于一个大小为n的输入,如果他的 ...

  6. 简单认识python cmd模块

    0X00 前言 在早前用别人的工具时,发现有些大佬会用到交互式shell,那时候就挺好奇的,但是一直都没有看一下怎么做到的. 今天在翻p牛的博客的时候,看到他早之前写的一个工具就有用到交互式shell ...

  7. ASP.NET MVC 解决区域和全局控制器同名的问题

    话不多少 直接上代码 通常我们以为上边的是解决控制同名问题,是解决了一点,但是又出了以下问题,默认请求的不是项目默认的控制器而是该区域的控制器,在我之前开发的项目中,默认指向的是区域下的home控制器 ...

  8. "软件随想录" 读书笔记

    人员管理: 三种方法: 军事化管理方法, 经济利益驱动法, 认同法. 军事化管理方法不行. 经济利益驱动法也不行. 认同法, 其中一条建议是一起干活的人一起吃饭. 但这种做法比较困难. 设计的作用 寸 ...

  9. 如何使用 Q#

    Q# 是微软的量子语言,很厉害,所以本文告诉大家如何入门,如何配置. 介绍 很多新的计数机技术都在很多年前就有人提出,量子计算就是其中一个.量子计算在 1980 年就被 Richard Feynman ...

  10. 【django基础】

    一.MTV模型 Django的MTV分别代表: Model(模型):负责业务对象与数据库的对象(ORM) Template(模版):负责如何把页面展示给用户 View(视图):负责业务逻辑,并在适当的 ...