共计 3264 个字符，预计需要花费 9 分钟才能阅读完成。
因为近期应用到 Taro 编写小程序，出于好奇，筹备研读一下 Taro 的源码。
在上一篇文章 Taro 源码解读 – taro build 篇 中，曾经解说了 taro-cli 的实现原理，而后以 taro build 为案例解释了外围 Kernel + 钩子的运行机制，以及最终达到 webpack 构建阶段。
本篇文章将会是对 taro build 篇的一个补充，着重介绍运行 taro build 后，最终 webpack 实现的打包机制，以及简略介绍一下 Taro Next 从编译时到运行时的转变。
话不多说，咱们开始吧。
miniRunner 概览
miniRunner 其实是一个函数，咱们先来整体看看 miniRunner 所做的事件吧（如下图）
咱们来逐行解析一下代码实现：
| 代码行数 | 解释 | ||
|---|---|---|---|
第 21 行 | 定义构建 mode，也就是 `”production” | “development” | “none”` |
第 24 行 | 欠缺构建配置，这里次要是欠缺一些 sass loader 的配置 | ||
第 27~37 行 | 依据我的项目配置生成 webpack 的构建配置 | ||
第 39~80 行 | 应用 webpack 进行代码编译 |
从下面的剖析能够看出，miniRunner 次要做的工作就是依据我的项目配置组装 webpack 配置，而后依据 webpack 配置生成编译后的代码。
接下来，咱们重点关注我的项目自带的 webpackChain 配置（第 27 行），看看默认的配置是什么样的吧~
默认配置
这里咱们以 taro build --type weapp 命令为例，将 react 技术栈的代码编译到微信小程序平台。
咱们先来看看默认配置（如下图）
咱们从下面的配置中能够看到 framework（框架）是 react，platform（指标平台）是 weapp（微信）。上面咱们来看看这份配置生成的 webpackChain，也就是 miniRunner 中的第 27 行代码（如下图）
接下来的解析也是对 webpack 配置的解析科普，可能会比拟干燥，大家急躁看完就晓得外部编译所做的事件了。
根底配置
咱们先找到 buildConf 函数（如下图）
从上图的第 27 行中能够看出，外部应用 getBaseConf 来获取一个初始设置（如下图）
上面咱们来逐行解析一下根底配置项，如下：
- 第
9行：源文件应用的扩展名，这里包含'.js', '.jsx', '.ts', '.tsx', '.mjs', '.vue'，值得注意的是，mjs指的是 JavaScript modules 模块 - 第
10行：指定导入模块时应用package.json中的哪个字段，这里的配置将优先应用browser属性解析文件，其次是module，最初是main。 - 第
11行：符号链接 (symlink) 解析到它们的符号链接地位(symlink location)。相干材料能够参考 当 webpack 遇上 symlink。 - 第
12~15行：通知 webpack 解析模块时应该搜寻的目录，这里对应的就是node_modules目录。 - 第
16~21行：这里是一些运行时的模块，将其指向本地 node_modules 顶层，以保障状态统一。 - 第
23~27行：解析webpack loader包，指定node_modules目录。 - 第
28~30行：代码包是蕴含副作用的，不心愿被tree shaking优化。 - 第
33~35行：增加taro自带的MultiPlatformPlugin插件，这个咱们在前面在开展介绍。
构建项配置
在梳理完了根底配置后，咱们来持续探索 buildConf 函数（如下图）。
从上图能够看出，第 98~100 行时，将 copy 属性解析为 copy-webpack-plugin 插件，退出到 webpack 中（如下图）
接下来几行代码则展现了一些从 React 到 微信小程序 两头的玄妙之处。（如下图）
从第 103 行能够看出，如果 framework 是 react，miniRunner 外部则会将 react-dom 指向 @tarojs/react。
在 react 体系中，react 库实现了 ReactComponent 和 ReactElement 的外围局部，而 react-dom 库负责通过操作 DOM 来实现 react 在浏览器中的渲染更新操作。在小程序中，并不能间接操作 DOM 树或者说没有传统的 DOM 树，此时间接应用 react-dom 则会导致报错。所以，taro 实现了一套在小程序上的 仿 react-dom 运行时，以保障 React 能够失常在小程序端渲染、更新节点。
咱们也能够这么了解，
react-dom是浏览器端的render，react-native是原生 APP 的render，而@tarojs/react是小程序上的render。
咱们接着往下看（如下图）
在第 119 行中，将一些常量进行收集，后续用 definePlugin 进行解决（如下图）
咱们接着往下看（如下图）
在第 120~133 行中，次要是依据 isBuildPlugin 变量（是否为打包插件）来确定 entryRes（入口资源）、defaultCommonChunks（默认的 chunk）。
接下来，miniRunner 注册了一系列的插件（如下图）
此时注册的插件包含：
| 代码行数 | 解释 |
|---|---|
第 134 行 | 定义 definePlugin 插件，用于定义一些全局变量 |
第 135 行 | 定义 TaroMiniPlugin 插件，该插件次要负责将 framework 源文件转换为 platform 平台代码 |
第 157 行 | 定义 MiniCssExtractPlugin 插件，该插件次要负责将所有的 css 文件提取到一个文件中 |
第 39~80 行 | 定义 ProvidePlugin 插件，该插件负责了一个外围性能，就是将运行时环境从浏览器环境切换到 taro 的运行时环境，比方将 window 替换成 @tarojs/runtime 中导出的 window |
TaroMiniPlugin 和 @tarojs/runtime 大家先做个笔记，咱们前面还要再开展解析。
咱们先接着往下看。（如下图）
在第 173~186 行中，次要是配置 js 和 css 文件的压缩插件（如下图）
在接下来，webpackChain 又合并了一系列的根底参数（如下图）
咱们来进行逐行解析：
- 第
189行：提供mode配置选项，告知webpack应用相应模式的内置优化。 - 第
190行：管制是否生成source-map。 - 第
191行：入口文件，也就是app.js。 - 第
192行：定义代码编译后的生产目录。 - 第
200行：指定指标（target）环境。 - 第
203行：合并alias别名选项。 - 第
204行：配置module，这里次要是配置一些不同的loader。 - 第
226行：配置plugin插件。 - 第
227行：手动配置了一些编译选项优化。
在合并完了一系列参数配置后，buildConf 最初进行了 vue 的兼容解决，最初将 chain 返回。（如下图）
配置项概览
在理解完了外部的 webpackChain(buildConf) 组成后，咱们来持续回到 miniRunner 中来看代码（如下图）
在上图第 30 行中，miniRunner 将外部 webpackChain 和开发者设置的 webpackChain 相结合，失去最终的 webpackChain（如下图）。
咱们来看看由这份 webpackChain 最终生成的 webpack 配置长什么样子吧~（如下图）
配置很长，咱们还是须要关注两个比拟重要的局部
一是 taro 外部插件 – TaroMiniPlugin（如下图）
二是 taro 外部 loader – miniTemplateLoader（如下图）
能够说，只有搞懂了 TaroMiniPlugin 和 miniTemplateLoader，就能搞懂从 React 到小程序的流程。
小结
TaroMiniPlugin 和 miniTemplateLoader 局部的内容比较复杂，咱们会在前面独自开设两个章节进行解说。
那么，本次对 miniRunner 的梳理到这里就算实现啦。
最初咱们画一个流程图来帮忙大家了解（如下图）
最初一件事
如果您曾经看到这里了，心愿您还是点个赞再走吧~
您的点赞是对作者的最大激励，也能够让更多人看到本篇文章！
如果感觉本文对您有帮忙，请帮忙在 github 上点亮 star 激励一下吧！
