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

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. which 命令详解

    一.which 作用: which 命令用于查找并显示给定命令的绝对路径,环境变量PATH中保存了查找命令时需要遍历的目录, which 命令会在环境变量$PATH 设置的目录里查找符合条件的文件.也 ...

  2. LindDotNetCore~基于模块化注入的介绍

    LindDotNetCore相关介绍 相关模块 全局都是依赖DI 消息队列 NoSql Caching 仓储 服务总线 Solr 调度 日志 Asspect拦截组件 UAA授权 各种组件环境的搭建 各 ...

  3. MySQL:表的操作 知识点难点总结:表完整性约束及其他常用知识点二次总结🙄

    表操作 一 : 修改表表表表表表表表表: ALTER TABLE 语法 1. 改表名rename alter table 表名 rename 新表名 2. 增加字段add alter table 表名 ...

  4. IOC的总结

    今天趁着空闲总结一下自己IOC的一些理解,希望可以帮助到有需要的人,请大牛们多多指教. (一)IOC IOC就是控制反转,给程序解耦等等,有很多博客都对它做了一些很好的讲解.在这里我也不说太多文字,直 ...

  5. Node.js 蚕食计划(五)—— Koa 基础项目搭建

    Koa 是由 Express 原班人马打造的超轻量服务端框架 与 Express 相比,除了自由度更高,可以自行引入中间件之外,更重要的是使用了 ES6 + async,从而避免了回调地狱 不过也是因 ...

  6. robotframework的学习笔记(十三)------Robot Framework常用库简介

    标准库 Robot Framework可以直接导入使用的库,包括: Builtin:包含经常需要的关键字.自动导入无需import,因此总是可用的 Dialogs:提供了暂停测试执行和从用户的输入方式 ...

  7. Python核心编程笔记--私有化

    一.私有化的实现 在Python中想定义一个类是比较简单的,比如要定义一个Person类,如下代码即可: # -*- coding: utf-8 -*- # __author : Demon # da ...

  8. 让git不再跟踪配置文件的变化

    我们经常会在配置文件里留下一些敏感信息 比如数据库链接字符串的用户名和密码 如果不提交配置文件到github或者其他源码管理网站 那么你的粉丝很可能就无法正确运行你的项目,就达不到开源的目的了 那么, ...

  9. linux下的磁盘挂载

    将新的磁盘安装在服务器上后,怎么挂载到现在的服务器上呢? 1.查询是否已经分配磁盘 fdisk -l 这里因为测试,只是挂载了10G的硬盘 2.发现有磁盘/dev/sdb.然后使用fdisk命令建立分 ...

  10. Python:名片管理系统

    字符串和列表学完, 自己试着写了一个非常简单的名片管理系统, 新萌尝试, 大佬们不要喷, 修改名片的功能我偷了个懒, 因为我不知道怎么通过定义下标,然后通过下标来修改列表内的字符串 我的思路是,把用户 ...