webpack关键库

序言

小伙伴们好欢迎来到阳九,一个被现实折磨得转换格式歪门邪道程序员.

近期或是想要做一期对webpack架构设计,编码分层次的全面分析。

很有可能这篇文章写好也就不再写webpack有关的东西了,或许不会再科学研究前面了还或许。

自己自身手写的webpack还在开展重新构建,要保持与源代码构造逻辑一致。

对webpack感兴趣的朋友可以看一下我的项目,相比硬啃webpack源代码,根据你的简单笔写版学习培训很有可能更有效率。

原生态JS笔写简单webpack 笔写React测试报告 (github.com)

tapable与plugin

在讲webpack源代码以前,一定要对tapable有一个清晰的认识.

Tapable是一个 JavaScript 库，用于支持在各个一部分中间引入自定功能性的软件架构。 我们通过tapable在webpack的每个编译程序环节插进不一样的思路,

但这些逻辑性被封装形式为了能软件Plugins。通过在各个阶段实行客户自定代码，

实际有关tapable的朋友可以在各类博客网站上搜索一下,到处都有。

对tapable源代码感兴趣的同学也可以参考一下这篇文章

webpack关键库 - tapable的设计理念与关键源码解析 - 程序编写 ()

Compiler

webpack的主类, 在webpack在所有编译程序周期初始阶段被建立, 并且在全部编译程序生命期中保持一致。 这一类承担载入环境变量、建立编译程序案例、运行编译过程等。

这一类中初始化了好几个派生类,例如

• Compilation: 单独编译程序步骤
• ModuleFactory: 控制模块加工厂
• ResolverFacory: 途径在线解析加工厂
• RequestShortener:途径简单化器
• watcher: 文档监控系统
• FileSystem:每个文件目录
• cache: 缓存文件

compiler主类承担融洽每个控制模块间的依存关系，保证全部搭建全过程可以顺利地继续下去。

总框架图:

Compilation

Compilation是指单独编译程序步骤, 与Compiler是一对多的是关联, 大家可以在Compiler中建立好几个Compilation步骤,

在此类里我们能解决输入文件,处理过的导出编码、依赖项等。

compilation整个搭建步骤,是由tapable的hooks,运转每个不同类型的软件达到的 每一个文档可以通过ModuleFactory构建一个控制模块目标, 把这个控制模块目标传到全部搭建环节中

• 各种各样template : 用以建立编码,应用模版将模块编码包囊成装包后产生的实际编码
• moduleGraph: 控制模块间的依赖图,叙述了控制模块间的依存关系
• moduleCache: 模块缓存文件
• ResolveFactory: 由compiler传到,用以建立resolver,便于ModuleFacory分析途径
• ModuleFacory: 控制模块加工厂, 会建立好几个module案例,添加编译程序步骤
• Logger: 内嵌logger

单独Compilatio的构造

ModuleFactory与Hooks执行过程

控制模块加工厂, 说白了,用以建立模块加工厂,

webpack含有各种不同的控制模块,不同种类的控制模块必须不一样的处理方式，因而webpack为每一种类别的控制模块都带来了对应的工厂类。

• NormalModule 一般控制模块
• ContextModule 前后文控制模块
• NullModule 空控制模块
• 别的

因此我们也有不同控制模块加工厂, 在其中最关键的就是NormalModuleFactory NormalModuleFactory关键进行了如下所示一些事:

1. 分析模块依存关系
2. 把它转换成AST（抽象语法树）。
3. 对AST进行相应的编译程序实际操作(根据各种各样软件,配备去进行)

相同的,控制模块工厂的解决都是通过tapable开展运转,我们将要一个文档分析塑造成控制模块目标Module,

Module目标会统计现阶段模块各种各样特性，如模块途径、所属 Chunk、编码具体内容等相关信息

建立的时候我们会把Module目标在多个hooks里的plugins中运转,

• 每一个Hook是一个生命期环节,内部结构提前注册了好几个plugin软件

• 每一个Plugin都是一个函数公式,会让控制模块具体内容进行一定的解决, 并把控制模块目标运转至下一个plugins中

• 绝大部分的软件全是webpack的自带软件,大家还可以通过配备,往webpack某个生命期勾子中加入自定软件,修改代码具体内容

下列是一个模块大概运转流程表

ResolverFactory

ResolverFactory是 webpack 中用以建立Resolver案例的工厂类。关键逻辑性由enhanced-resolve库来开展完成,

Resolver用以将控制模块要求（如require/import申明）分析为目标文件夹或控制模块ID。

比如大家写require('./index'),resolver便会用它分析出./index的一体化途径。

const { ResolverFactory, CachedInputFileSystem } = require("enhanced-resolve");
const fs = require("fs");
const path = require("path");

const myResolver = ResolverFactory.createResolver({ 
fileSystem: new CachedInputFileSystem(fs, 4000), 
extensions: [".json", ".js", ".ts"], 
})

myResolver.resolve(path,request,context, (err, path, result) => {
   // 接收的result是 分析引入的path和request后的结果
   console.log(result)
});

相同的, Resolver将传到的目标文件夹外包装为一个request目标, 根据tapable将request目标在各类软件中运转

有关enhanced-resolve,详尽的可参照这篇文章

根据enhanced-resolve领略到webpack的软件架构设计 - 程序编写 ()

RequestShortener

RequestShortener是Webpack中的一个协助类，用以减少和装饰网络资源途径。 实质上并没有实现什么领域模型,仅仅恰好看见了,直接放出去讲下。

在Webpack编译过程中，假如遇到了一些错误或警示，Webpack会抛出去一些信息，这些数据一般包括了一些网络资源的路线信息内容，比如源代码目标文件夹、依靠控制模块途径等。

这种途径信息内容一般都很长，用起来很不方便

// 原途径
/root/project/src/components/Header/index.js
// 应用`RequestShortener.shorten()`方式可将其转换成绝对路径：
./components/Header/index.js

文件目录

webpack中一共初始化了四种文件目录

• inputFileSystem 缓存系统软件
• outputFileSystem 导出文件目录
• watchFileSystem 文档视频监控系统
• intermediateFileSystem 正中间(件)文件目录

这四种文件目录分别带来了不一样的功效,基本都是由Node.js原生态封装形式出的系统软件。 能看我另一篇文章去了解这四种文件目录以及作用

详说webpack里的4种文件目录 - 程序编写 ()

末尾

在重新构建完自已的webpack后,我希望能开源系统并宣传策划一下自己的webpack项目,

热烈欢迎感兴趣的小伙伴们与我联系,一起参与mini-webpack项目地构建。