共计 2989 个字符，预计需要花费 8 分钟才能阅读完成。
本篇文章是 Taro 的源码解读系列的第五篇文章，上面是系列文章链接。
- Taro 源码解读 – @tarojs/taro 篇
- Taro 源码解读 – @tarojs/cli 篇
- Taro 源码解读 – taro build 篇
- Taro 源码解读 – miniRunner 篇
- Taro 源码解读 – TaroMiniPlugin 上篇
在上一篇文章 Taro 源码解读 – miniRunner 篇 中，曾经解说了 taro-cli 中 miniRunner 的工作流程，实质上是 webpack 构建流程。
本篇文章将会是对 miniRunner 篇的一个补充，着重介绍 miniRunner 中的 TaroMiniPlugin。
话不多说，咱们开始吧。
TaroMiniPlugin 概览
TaroMiniPlugin 是一个 webpack plugin，依据 webpack 插件个性，在装置插件时，将会调用插件实例上的 apply 办法。而 apply 办法个别实现的都是在 webpack compiler 的不同生命周期中注册对应的钩子函数，用于在特定的机会解决额定的逻辑。
咱们先来看看 TaroMiniPlugin 中的 apply 办法吧（如下图）
咱们来剖析 TaroMiniPlugin 的 apply 办法所做的事件，如下：
| 代码 | 剖析 |
|---|---|
第 148 - 156 行 | 获取插件传入的一些参数，获取入口文件门路 |
第 158 行 | 注册生命周期钩子函数，当 webpack 开始编译时执行 |
第 174 行 | 注册生命周期钩子函数，在 webpack 监听模式下，一个新的编译被触发之后执行 |
第 197 行 | 注册生命周期钩子函数，在 webpack 实现编译之前执行 |
第 211 行 | 注册生命周期钩子函数，在 compilation 创立胜利之后执行，compilation 代表一次独自的编译 |
第 281 行 | 注册生命周期钩子函数，在 webpack 生成资源到 output 目录之前执行 |
第 288 行 | 注册生命周期钩子函数，在 webpack 生成资源到 output 目录之后执行 |
第 295 行 | 在注册完了生命周期钩子函数后，持续调用 TaroNormalModulesPlugin 插件的 apply 办法 |
接下来咱们须要对 apply 注册的几个生命周期钩子函数进行解析。咱们先看看 appEntry 的值，也就是咱们的入口文件（如下图）。
生命周期钩子 – run
咱们当初就从 TaroMiniPlugin 注册的一个钩子 run 开始解析，代码实现如下图
TaroMiniPlugin 应用 tapAsync 调用了一个异步钩子，钩子的名词是变量 PLUGIN_NAME，也就是 TaroMiniPlugin。
而后咱们看到第 161 行，在这行代码中，调用了 TaroMiniPlugin 实例中的 run 办法，并将 compiler 作为参数传入。在 run 办法执行实现后，调用了 TaroLoadChunksPlugin 插件，这就是注册在 run 生命周期的钩子函数。
让咱们来看看这个钩子函数中，一开始调用的 run 办法的实现吧。（如下图）
从上图代码的正文中，咱们能够得悉，run 办法所做的工作就是先剖析 app 入口文件，再收集页面、组件信息，最初再往 dependencies 属性中增加资源模块。
获取 AppConfig
进入到 run 办法，咱们先来看看获取 app 配置这一步吧。这一步调用了 getAppConfig 办法，其实是剖析 app.config.js，也就是 Taro 官网提供的小程序配置文件。（如下图）
这里次要是收集了小程序的根底配置，除此之外，Taro 针对 usingComponents 注册的全局自定义组件做了解决，将其收集到了外部 components 属性中，以便前面应用。
最初收集到的配置相似于下图中展现的根底配置，而后将其存储在 TaroMiniPlugin 实例中的 appConfig 属性中。（如下图）
收集小程序页面、组件信息
接下来，咱们来看看 getPages 办法。（如下图）
在 getPages 办法中，次要做了这么几个工作：
| 代码行数 | 阐明 |
|---|---|
第 364 行 | 收集须要预渲染的页面 |
第 365 行 | 收集 tabbar 文件，次要是解决收集 tabbar 中的自定义组件 |
第 366 行 | 收集页面，存储在 pages 属性中 |
第 380 行 | 收集分包配置中的页面 |
在 getPages 办法中值得关注的是，pages 最初收集的属性不只是门路信息，还会剖析出一些其余信息，譬如是否为小程序原生页面或组件、页面名称、页面文件门路 …（如下图）
在页面全副收集实现后，会对页面进行读取，并剖析依赖关系，也就是 getPagesConfig 办法。（如下图）
在这一步中，次要是剖析页面依赖的组件关系，并存储在 components 信息中。而后，就会呈现咱们相熟的一个 Taro 编译启动提醒界面啦~（如下图）
在剖析完了页面组件之间的依赖关系后，会通过 getDarkMode 办法获取我的项目的 darkmode 配置，将主题信息存储在 TaroMiniPlugin 实例的 themeLocation 属性中。
收集依赖关系
在收集完了小程序页面配置文件和组件文件后，进入到下一步，进行一些依赖关系的收集。
咱们先来看看 getConfigFiles 办法。（如下图）
从上图能够看出，该办法会从 fileConfigs 中取出所有配置，而后将其增加到 dependencies 中。而后，注册了一个 webpack 钩子函数，在创立 chunk assets 之前，把所有的 config 相干 chunk 移除。
在依赖收集实现后，dependencies 是一个 Map 实例，记录了 config 配置文件的相干信息。（如下图）
在 config 文件收集实现后，又通过 addEntries 将 app、模板组件、页面、组件等资源模块信息，都记录在了 dependencies 中。（如下图）
到了这里，run 办法流程执行实现，将我的项目中一些根底的页面、组件、依赖关系都收集实现。并且，将这些信息记录在 TaroMiniPlugin 实例中，而后将资源模块相干信息记录在 dependencies 属性中。
在 TaroMiniPlugin 插件中，遵循了 繁多职责 设计准则，在 run 办法中基本上只做了我的项目信息收集的工作，并没有做任何产生副作用的操作。遵循 繁多职责 设计准则，能够使 TaroMiniPlugin 的工作流程变得更加清晰，也让咱们的源码浏览更加简略 (*~︶~).
TaroLoadChunksPlugin
在 run 钩子时，除了运行 run 办法收集完了我的项目相干根底信息以外，还调用了另一个插件 TaroLoadChunksPlugin。
这个插件的次要作用就是解决我的项目中须要提取的公共文件。具体内容能够参考 Taro-commonChunks、webpack-runtimeChunk、webpack-spiltChunks。
小结
以上就是 TaroMiniPlugin 中注册的第一个钩子 run 所做的事件，这个钩子函数将会在开始编译时执行，次要所做的事件就是将我的项目中一些根底的页面、组件、依赖关系收集实现，记录在 TaroMiniPlugin 中，以便在前面的编译步骤中应用。
在前面的文章中，咱们将陆续对 TaroMiniPlugin 中注册的其余 webpack 钩子进行具体解析，如庖丁解牛般将 TaroMiniPlugin 源码清晰解读。
最初一件事
如果您曾经看到这里了，心愿您还是点个赞再走吧~
您的点赞是对作者的最大激励，也能够让更多人看到本篇文章！
如果感觉本文对您有帮忙，请帮忙在 github 上点亮 star 激励一下吧！
