随笔分类 - webpack源码系列
摘要：因为换了个工作，所以博客停了一段时间。 这是上个月留下来的坑，webpack的源码已经不太想看了，又臭又长，恶心的要死，想去看node的源码……总之先补完这个 上一节完成了babel-loader对JS文件字符串的转换，最后返回后进入如下代码： 在看这个parse方法之前，需要过一下参数，首先是这个
阅读全文
摘要：经过非常非常长无聊的流程，只是将获取到的module信息做了一些缓存，然后生成了loaderContext对象。 这里上个图整理一下这节的流程： 这一节来看webpack是如何将babel-loader与js文件结合的，首先总览一下runLoaders函数： 传入的4个参数都很直白： 1、待处理文件
阅读全文
摘要：赶紧完结这个系列咯，webpack4都已经出正式版了。 之前的代码搜索到js文件的对应loader，并添加到了对象中返回，流程如下： 这个对象的request将入口文件的路径与loader拼接起来并用！分割，所有的属性基本上都与路径相关。 after-resolve事件流 这里会触发after-re
阅读全文
摘要：眼看webpack4都出了，我还在撸3的源码，真的是捉急啊…… 不过现在只是beta版本，等出稳定版本后跑跑4的源码去。 之前漏了一个东西没有讲，如下： 在解析完入口文件路径与JS文件对应的babel-loader路径后，返回的包装对象多了一个parser属性，看似简单，实则麻烦的要死。 这里的参数
阅读全文
摘要：哈哈，上首页真难，每次都被秒下，心疼自己1秒~ 这里补充一个简要图，方便理解流程： 在处理./input.js入口文件时，在类型判断被分为普通文件，所以走的文件事件流，最后拼接得到文件的绝对路径。 但是对应"babel-loader"这个字符串，在如下正则中被判定为模块类型： 因此，参考第33节的流
阅读全文
摘要：新年好呀~过个年光打游戏，function都写不顺溜了。 上一节的代码到这里了： 经过长长的resolve，最终也只是解析入口文件的合法路径信息，然后调用回调函数。 接下来分析回调函数是如何处理返回结果的： 返回的结果有两部分，一个是loader，一个是文件对应路径。 对于入口文件的当前解析，不存在
阅读全文
摘要：file => FileExistsPlugin 这个事件流快接近尾声了，接下来是FileExistsPlugin，很奇怪的是在最后才来检验路径文件是否存在。 源码如下： 这里只是简单的对路径文件进行状态获取，然后判断是否存在？是否是文件？最后调用一个有message的doResolve方法进入到下
阅读全文
摘要：流程图如下： 重回DescriptionFilePlugin 上一节最后进入relative事件流，注入地点如下： 这似曾相识的感觉，这不就是解析package.json的插件么，又调用了一次。 但是有一点点微妙的不同，第一次调用该插件时，request对象如下所示： 在经过几个插件的洗礼后，变成了
阅读全文
摘要：放个流程图： 这里也放一下request对象内容，这节完事后如下(把vue-cli的package.json也复制过来了)： 上一节看到这： 这里接下来会调用runAfter方法，之前有讲解过这个，简单讲就是触发after-type的事件流，这里的type为parsed-resolve，即触发aft
阅读全文
摘要：这里所有的插件都对应着一个小功能，画个图整理下目前流程： 上节是从ParsePlugin中出来，对'./input.js'入口文件的路径做了处理，返回如下： 该插件调用完后，进入下一个事件流，开始跑跑parsed-resolve相关的了。 回头看了一眼28节的大流程图，发现基本上这些事件流都是串联起
阅读全文
摘要：在上一节中，最后返回了一个resolver，本质上就是一个Resolver对象： 这个对象的构造函数非常简单，只是简单的继承了Tapable，并接收了fileSystem参数： resolve 而在make事件流中，调用的正是该类的原型方法resolve，现在可以进行看一眼了： 需要注意的是，该方法
阅读全文
摘要：原本该在过WebpackOptionsApply时讲解这个方法的，但是当时一不小心过掉了，所以在这里补上。 compiler.resolvers 该对象的三个方法均在WebpackOptionsApply中生成，代码如下： 由于调用的是一个工厂函数，所以用normal作为示例讲解。 其中参数中的re
阅读全文
摘要：上一节跑到了NormalModuleFactory模块，调用了原型方法create后，依次触发了before-rsolve、factory、resolver事件流，这节从resolver事件流开始讲。 源码简化如下： 第一次进来这个函数传入的是entry，在这里对字符串进行正则校验与切割，一般情况下
阅读全文
摘要：compilation事件流中，依然只是针对细节步骤做事件流注入，代码流程如图： 触发完compilation事件流后，会直接返回一个compilation对象，然后触发下一个事件流make。 make的来源在EntryOptionPlugin插件中，无论entry参数是单入口字符串、单入口数组、多
阅读全文
摘要：这一节跑下一批plugin。 希望不要跟上一节一样，全是plugin。 流程如图(看看流程图就行了，后面也没有什么内容)： EnsureChunkConditionsPlugin 这个看看就懂，不解释了。 RemoveParentModulesPlugin 难道又是另一批plugin么…… Remo
阅读全文
摘要：下一个compilation来源于以下代码： 之前简单分析该处的apply，此处只看非数组单入口的情况，此时会引入SingleEntryDependency模块，与compilation相关的内容如下： 此处用到了ES6新加的数据结构Map，SingleEntryDependency是个没什么营养的
阅读全文
摘要：正式开始跑编译，依次解析，首先是： 流程图如下： 这里是第一个compilation事件注入的地方，注入代码如下： 这里的requestShortener为FunctionModulePlugin的第二个参数，没有传所以是undefined。 options.output为传入的output参数，但
阅读全文
摘要：呃，终于到了这地方…… MMP，有31个函数，估计可以写到明年了。 这里先梳理所有事件的注入来源，经检测，全部来源于WebpackOptionsApply中，回到那个可怕的模块，梳理后如下： 还好都集中在一个地方，这样又可以写流水账了。 这里先要过一个地方，之前似乎遗留了： 这里注入了entry-o
阅读全文
摘要：上一节生成Compilation实例后，添加了一些属性，随后触发this-compilation事件流，如下： 事件流的名字this-compilation我想了半天也不懂啥意思，从其内容来看其实也只算是一个预编译，叫pre-compilation似乎更好。 总之先不管那么多，继续跑流程，流程图如下
阅读全文
摘要：这里的编译前指的是开始触发主要的事件流this-compilaiton、compilation之前，由于还有一些准备代码，这一节全部弄出来。 模块基本上只走构造函数，具体的方法调用的时候再具体讲解。 上一节NormalModuleFactory模块的构造函数中，在处理完rules后，注入两个事件流就
阅读全文