本篇文章是 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
激励一下吧!