正式开始跑编译,依次解析,首先是:

compiler.apply(
new JsonpTemplatePlugin(options.output),
// start
new FunctionModulePlugin(options.output),
new NodeSourcePlugin(options.node),
new LoaderTargetPlugin(options.target)
);

  流程图如下:

  这里是第一个compilation事件注入的地方,注入代码如下:

compiler.plugin("compilation", (compilation) => {
compilation.moduleTemplate.requestShortener = this.requestShortener || new RequestShortener(compiler.context);
compilation.moduleTemplate.apply(new FunctionModuleTemplatePlugin());
});

  这里的requestShortener为FunctionModulePlugin的第二个参数,没有传所以是undefined。

  options.output为传入的output参数,但是这里并没有用到,而是传入了compiler.context,如果没有传默认为命令执行路径。

  

RequestShortener

  首先看第一个,源码简化如下:

"use strict";

const path = require("path");
// 匹配反斜杠 => \
const NORMALIZE_SLASH_DIRECTION_REGEXP = /\\/g;
// 匹配特殊字符
const PATH_CHARS_REGEXP = /[-[\]{}()*+?.,\\^$|#\s]/g;
// 匹配正反斜杠 => /\
const SEPARATOR_REGEXP = /[/\\]$/;
// 匹配以'!'开头或结尾
const FRONT_OR_BACK_BANG_REGEXP = /^!|!$/g;
// 匹配 /index.js
const INDEX_JS_REGEXP = /\/index.js(!|\?|\(query\))/g;
// 将反斜杠替换为正斜杠
const normalizeBackSlashDirection = (request) => {
return request.replace(NORMALIZE_SLASH_DIRECTION_REGEXP, "/");
};
// 将路径中特殊字符转义 例如 - => \-
// 返回一个正则
const createRegExpForPath = (path) => {
const regexpTypePartial = path.replace(PATH_CHARS_REGEXP, "\\$&");
return new RegExp(`(^|!)${regexpTypePartial}`, "g");
}; class RequestShortener {
constructor(directory) { /**/ }
shorten(request) { /**/ }
} module.exports = RequestShortener;

  可以看到都是对路径做处理,正则都比较简单,接下来看一下构造函数,其中传进来的directory为命令执行上下文。

class RequestShortener {
constructor(directory) {
// 斜杠转换
directory = normalizeBackSlashDirection(directory);
// 没看懂啥用
if (SEPARATOR_REGEXP.test(directory)) directory = directory.substr(0, directory.length - 1);
// 上下文路径正则
// /(^|!)转义后的路径/g
if (directory) {
this.currentDirectoryRegExp = createRegExpForPath(directory);
}
// 返回目录名
const dirname = path.dirname(directory);
// 这里也不懂干啥用的
const endsWithSeperator = SEPARATOR_REGEXP.test(dirname);
const parentDirectory = endsWithSeperator ? dirname.substr(0, dirname.length - 1) : dirname;
// 目录正则
if (parentDirectory && parentDirectory !== directory) {
this.parentDirectoryRegExp = createRegExpForPath(parentDirectory);
}
// .....\node_modules\webpack\lib
if (__dirname.length >= 2) {
// webpack的目录
const buildins = normalizeBackSlashDirection(path.join(__dirname, ".."));
// 目录检测
const buildinsAsModule = this.currentDirectoryRegExp && this.currentDirectoryRegExp.test(buildins);
// false
this.buildinsAsModule = buildinsAsModule;
// 生成webpack目录路径正则
this.buildinsRegExp = createRegExpForPath(buildins);
}
}
shorten(request) { /**/ }
}

  主要是生成了3个目录匹配正则,上下文、上下文目录、webpack主目录三个。

  这里上下文一般不会是webpack的目录,所以这个buildingsAsModule理论上都是flase。

  再简单看一下原型方法shorten:

class RequestShortener {
constructor(directory) { /**/ }
shorten(request) {
if (!request) return request;
// 转化路径斜杠
request = normalizeBackSlashDirection(request);
// false
if (this.buildinsAsModule && this.buildinsRegExp)
request = request.replace(this.buildinsRegExp, "!(webpack)");
// 将上下文转换为!.
if (this.currentDirectoryRegExp)
request = request.replace(this.currentDirectoryRegExp, "!.");
// 将上下文目录转换为!..
if (this.parentDirectoryRegExp)
request = request.replace(this.parentDirectoryRegExp, "!..");
// false
if (!this.buildinsAsModule && this.buildinsRegExp)
request = request.replace(this.buildinsRegExp, "!(webpack)");
// 把路径中的index.js去了 留下参数
// /index.js?a=1 => ?a=1
request = request.replace(INDEX_JS_REGEXP, "$1");
// 把头尾的!去了
return request.replace(FRONT_OR_BACK_BANG_REGEXP, "");
}
}

  可以看出,这个方法将传入的路径根据上下文的目录进行简化,变成了相对路径,然后去掉了index.js。

FunctionModuleTemplatePlugin

  这个模块没有实质性内容,主要是对compilation.moduleTemplate注入事件流,源码如下:

"use strict";

const ConcatSource = require("webpack-sources").ConcatSource;

class FunctionModuleTemplatePlugin {
apply(moduleTemplate) {
moduleTemplate.plugin("render", function(moduleSource, module) { /**/ });
moduleTemplate.plugin("package", function(moduleSource, module) { /**/ });
moduleTemplate.plugin("hash", function(hash) { /**/ });
}
}
module.exports = FunctionModuleTemplatePlugin;

  等触发的时候再回头看。

  ConcatSource后面单独讲。

  下面是第二个插件,源码整理如下:

class NodeSourcePlugin {
constructor(options) {
this.options = options;
}
apply(compiler) {
const options = this.options;
if (options === false) // allow single kill switch to turn off this plugin
return; function getPathToModule(module, type) { /**/ } function addExpression(parser, name, module, type, suffix) { /**/ }
compiler.plugin("compilation", function(compilation, params) {
params.normalModuleFactory.plugin("parser", function(parser, parserOptions) { /**/ });
});
compiler.plugin("after-resolvers", (compiler) => { /**/ });
}
};

  可以看到,这里只是简单判断了是否关闭了node插件,然后在之前的params参数中的normalModuleFactory属性上注入了一个parser事件。

  第三个插件就更简单了,如下:

class LoaderTargetPlugin {
constructor(target) {
this.target = target;
}
apply(compiler) {
compiler.plugin("compilation", (compilation) => {
// 这个完全不懂干啥的
compilation.plugin("normal-module-loader", (loaderContext) => loaderContext.target = this.target);
});
}
}

  这个plugin目前根本看不出来有什么用。

  总之,前三个compilation比较水,没有什么内容。

.23-浅析webpack源码之事件流compilation(1)的更多相关文章

  1. .24-浅析webpack源码之事件流compilation(2)

    下一个compilation来源于以下代码: compiler.apply(new EntryOptionPlugin()); compiler.applyPluginsBailResult(&quo ...

  2. .22-浅析webpack源码之事件流compilation总览

    呃,终于到了这地方-- newCompilation(params) { // ... this.applyPlugins("this-compilation", compilat ...

  3. .25-浅析webpack源码之事件流compilation(3)

    这一节跑下一批plugin. compiler.apply( new EnsureChunkConditionsPlugin(), new RemoveParentModulesPlugin(), n ...

  4. .21-浅析webpack源码之事件流this-compilation

    上一节生成Compilation实例后,添加了一些属性,随后触发this-compilation事件流,如下: Compiler.prototype.newCompilation = (params) ...

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

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

  6. .27-浅析webpack源码之事件流make(2)

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

  7. .26-浅析webpack源码之事件流make(1)

    compilation事件流中,依然只是针对细节步骤做事件流注入,代码流程如图: // apply => this-compilation // apply => compilation ...

  8. .37-浅析webpack源码之事件流make(4)

    赶紧完结这个系列咯,webpack4都已经出正式版了. 之前的代码搜索到js文件的对应loader,并添加到了对象中返回,流程如下: this.plugin("factory", ...

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

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

随机推荐

  1. Spring之DAO一

    前面博客把bean.aop简单了解了一下,今天主要是了解Spring中DAO层,如果使用传统的JDBC时需要创建连接.打开.执行sql.关闭连接这一系列的步骤,Spring框架对JDBC进行了封装,我 ...

  2. c#加密解密源码,md5、des、rsa

    从网上找来的代码,顺手改改,用起来更方便. 配置文件 using System; using System.Collections.Generic; using System.Text; using ...

  3. 伽罗瓦域(有限域)GFq^12上元素的1→2→4→12塔式扩张(1)------第一次扩张

    伽罗瓦域是抽象代数下的域论分支中的内容,这部分想必很多人都比较熟悉,此处不再赘述. 最近,国密算法中的SM2和SM9已经成为国际标准,其中SM9算法在椭圆曲线离散对数难题的基础上,添加了若干个双线性配 ...

  4. Linux文件的复制、删除和移动命令

    cp命令  功能:将给出的文件或目录拷贝到另一文件或目录中,就如同DOS下的copy命令一样,功能非常强大.  语法:cp [选项] 源文件或目录 目标文件或目录  说明:该命令把指定的源文件复制到目 ...

  5. android之monkey测试

    本文同时发表于本人个人网站 www.yaoxiaowen.com monkey测试算是android自动化测试当中最简单的一种工具了.虽然简单,不过对于测试app的稳定健壮,减少崩溃还是比较有用的.所 ...

  6. Java的虚方法

    虚方法出现在Java的多态特性中, 父类与子类之间的多态性,对父类的函数进行重新定义.如果在子类中定义某方法与其父类有相同的名称和参数,我们说该方法被重写 (Overriding).在Java中,子类 ...

  7. python 多进程开发与多线程开发

    转自: http://tchuairen.blog.51cto.com/3848118/1720965 博文作者参考的博文:  博文1  博文2 我们先来了解什么是进程? 程序并不能单独运行,只有将程 ...

  8. golang 栈操作

    Monk's Love for Food   Our monk loves food. Hence,he took up position of a manager at Sagar,a restau ...

  9. ElfJS从入门到精通(一)

    介绍 Elf.js是一个简洁的高效的JavaScript框架.它不仅高度重视用户的体验,也高度重视开发者的体验.在实现当今主流技术的同时,以尽可能原生态的形式展现出来.在如今花样繁多的框架中,你是否感 ...

  10. vue2.0 如何在hash模式下实现微信分享

    最近又把vue的demo拿出来整理下,正好要做"微信分享"功能,于是遇到新的问题: 由于hash模式下,带有"#",导致微信分享的签证无效:当改成history ...