众所周知,taro-cli是Taro脚手架初始化和项目构建的的命令行工具,它的实现原理,相信大家从Taro 技术揭秘:taro-cli这篇文章中已经有所了解;本文将对其中的项目构建build命令进行分析,从cli层面了解taro构建的过程到底做了什么;
build命令的注册
在执行npm install -g @tarojs/cli时,npm通过读取package.json文件中的bin字段,将taro这个命令注册到[prefix]/bin中作为全局命令;
如果在当前项目目录下,执行npm install @tarojs/cli,则会将taro这个命令注册到./node_modules/.bin/底下作为本地命令;
// package.json
"bin": {
"taro": "bin/taro"
}
由于npm config get prefix为/usr/local,所以全局命令将会被注册到/usr/local目录底下,通过symlink符号链接的方式,使得/usr/local/bin/taro指向/usr/local/lib/node_modules/@tarojs/cli/bin/taro;
bin/taro文件作为taro-cli的入口,内部使用commander.js来解析命令中的参数,并且支持git风格的子命令处理,可以根据子命令自动引导到[command]-[subcommand]格式命名的执行文件;
所以当执行taro build命令时,则被commander.js自动引导到bin/taro-build文件下,继而执行bin/taro-build的逻辑;
build命令的分发
taro build命令功能非常多,它能够支持:
- 1、构建
H5;
taro build --type h5
- 2、构建小程序及小程序插件,支持
weapp/swan/alipay/tt/qq/jd类型;
// 小程序
taro build --type weapp
// 小程序插件
taro build --plugin weapp
- 3、构建UI库;
cross-env TARO_BUILD_TYPE=component taro build --ui
taro-build接收--type参数的值,接收到的结果交由dist/build.js的build函数进行判断,通过判断不同type的值,决定执行对应平台构建类型的逻辑,例如,当--type为h5时,则执行dist/h5/index.js文件中build函数的逻辑;当--type为weapp时,则执行dist/mini/index.js文件中build逻辑;
h5的构建逻辑
h5的构建流程主要经过:源代码 => 中间代码 => 目标代码的转换; 其中:
- 源代码:一般是指
src目录底下的代码,如果config中有配置sourceRoot,则源代码入口就为sourceRoot; - 中间代码:指
.temp目录下的代码,由taro-build实现的中间流程,主要通过babel实现中间代码的转换和生成; - 目标代码:指最终运行在浏览器的代码,一般指
dist目录下的代码,如果config中配置outputRoot,则目标代码将输出在outputRoot;
所以,三种代码间的转换关系可以用下图表示:

taro-build帮助将源代码转换成中间代码,并保存在.temp文件夹中,中间代码再交由webpack进行打包构建生成目标代码;
中间代码的生成
为什么会有中间代码生成这个步骤呢,这是因为:
- 直接将
源代码交由webpack进行编译,会出现部分方法的缺失、页面无法找到等的问题; Taro需要根据构建平台的类型进行一系列的转换,并导入对应平台的核心包;- 还需要根据工程或者页面的
config对源代码进行转换,并插入一些关键代码;
中间代码的生成流程需要转换的代码主要以src目录下的代码为主,而且只分析和转换js和ts的文件,因为涉及到代码的分析,所以借助了babel工具链,例如babel-core、babel-traverse、babel-types和babel-template等核心包中的方法进行处理,主要流程如下:
- 1、区分是否为
js或ts,是则进行分析,否则直接复制; - 2、分析文件是否为
ENTRY文件,PAGE文件,NORMAL文件,分类完成,则交由对应的处理函数进行处理; - 3、处理解析
ENTRY文件; - 4、处理解析
PAGE文件和NORMAL文件; - 5、处理完后的代码生成到
.temp文件夹中; - 6、调用
webpack-runner,对.temp文件的代码进行处理,生成到dist文件夹中;

ENTRY文件的分析
ENTRY类型的文件,由processEntry函数处理,通过babel-traverse中的traverse方法对不同类型的AST节点进行分析,其中涉及到很多细节,主要流程如下:
- 1、解析
config这个ClassProperty节点的内容,获取pages和subPages; - 2、依赖纠正:主要转换
tarojs/taro、tarojs/mobx、tarojs/redux相关依赖为tarojs/taro-h5、tarojs/mobx-h5、tarojs/redux-h5;转换ImportDeclaration节点中的alias别名;引入Nervjs核心包; - 3、在
render函数中,加入页面的Router组件(根据pages和subPages),Provider组件,Tabbar组件; - 4、引入
taro-router相关代码;

PAGE文件和NORMAL文件的分析
PAGE类型和NORMAL类型的文件,由processOthers函数处理,也是通过babel-traverse中的traverse方法对不同类型的AST节点进行分析,这里只列出主要流程:
- 1、依赖纠正:主要转换
tarojs/taro、tarojs/mobx、tarojs/redux相关依赖为tarojs/taro-h5、tarojs/mobx-h5、tarojs/redux-h5;转换ImportDeclaration节点中的alias别名;引入Nervjs核心包; - 2、解析
config这个ClassProperty节点的内容,获取配置项,对页面添加相关的组件和函数,例如PullDownRefresh组件和onPageScroll方法; - 3、导出纠正:当前类的
nameExport纠正为defaultExport,例如:当前文件page-index.js
// 纠正前
export class PageIndex extends Component {
...
}
// 纠正后
class PageIndex extends Component {
...
}
export default PageIndex;
- 4、声明纠正:当前
ClassExpression或ClassDeclaration中,在没有identifier的情况下,添加默认的identifier为_TaroComponentClass:
// 纠正前
export default class extends Component {
...
}
// 纠正后
export default class _TaroComponentClass extends Component {
...
}
webpack-runner逻辑
中间代码生成后,缓存在.temp文件夹底下,并且作为webpack-runner的入口文件,taro-build在完成buildTemp的流程后,就会继续执行调用webpack-runner的逻辑;webpack-runner的逻辑实际上就是根据定义好的webpack的配置,生成目标代码的流程,后面将会有单独的一篇文章详述相关配置,这里不做再多的描述;
小程序的构建逻辑
taro-build的小程序构建逻辑不存在中间代码的生成,而是直接由源代码生成小程序能运行的目标代码;这里的源代码是指遵循React规范的taro代码,这种代码在小程序的容器中是无法直接运行的,所以需要通过taro-build转换成小程序可运行的代码,因此在这个流程中涉及大量的AST语法解析和转换;
小程序的构建流程主要分三步完成(当然这里还有很多细节,但本文暂不详细阐述):
- 构建入口:指构建
sourceDir指定的文件,默认是app.jsx文件,构建的逻辑由buildEntry函数完成; - 构建页面:指构建在
app.jsx文件中的config.pages配置好的页面文件,主要由buildPages函数完成; - 构建组件:指构建页面文件中依赖的组件,主要由
buildSingleComponent函数完成;
构建流程需要依赖taro-transformer-wx包去解析JSX语法,已经对源代码的AST语法树,进行代码插入和转换;
buildEntry逻辑
构建入口的逻辑大概如下:
- 1、调用
taro-transformer-wx中的wxTransformer方法转换JSX语法; - 2、将
app.jsx中的es6语法通过babel转换为es5,并且引入taro-weapp核心包; - 3、通过AST转换,插入调用
taro-weapp包中createApp函数的语句; - 4、生成
app.json、app.js、app.wxss文件;
buildPages逻辑
构建页面的逻辑大概如下:
- 1、调用
taro-transformer-wx中的wxTransformer方法转换JSX语法; - 2、将页面js中的
es6语法通过babel转换为es5,并且引入taro-weapp核心包; - 3、通过AST转换,插入调用
taro-weapp包中createComponent函数的语句; - 4、编译页面所依赖的组件文件,由
buildDepComponents函数实现; - 5、生成页面对应的
page.json、page.js、page.wxss、page.wxml文件;
buildComponent逻辑
构建组件与构建页面类似,但多了递归的步骤,其逻辑大概如下:
- 1、调用
taro-transformer-wx中的wxTransformer方法转换JSX语法; - 2、将组件js中的
es6语法通过babel转换为es5,并且引入taro-weapp核心包; - 3、通过AST转换,插入调用
taro-weapp包中createComponent函数的语句; - 4、
递归编译组件所依赖的组件文件,由buildDepComponents函数实现; - 5、生成页面对应的
page.json、page.js、page.wxss、page.wxml文件;
taro-transformer-wx
taro将JSX解析到小程序模板的逻辑,单独拆成一个包taro-transformer-wx,里面涉及到大量的AST解析和转换,本文由于篇幅的关系,暂时不详细分析,希望后面会有单独的文章去分析小程序AST转换的流程,敬请期待;
结语
总的来说,从cli层面去看taro的构建流程,会发现为了兼容多平台,taro会使用较多的AST解析和转换,帮助将React规范的taro代码转换到对应平台能够运行的代码;这里也告诉我们,作为一个前端er,学习和掌握AST相关知识,能让你看到更大的世界!
最后,本文作为一篇原理分析的文章,如有疏漏以及错误,欢迎大家批评指正!