插件功能
Taro 引入了插件化机制,目的是为了让开发者能够通过编写插件的方式来为 Taro 拓展更多功能或为自身业务定制个性化功能。
#
插件集合#
官方插件- @taro/plugin-mini-ci,小程序持续集成插件。感谢 @bigmeow 的贡献!
- @tarojs/plugin-mock,一个简易的数据 mock 插件。
#
社区优质插件#
如何引入插件你可以从 npm 或者本地中引入插件,引入方式主要通过 编译配置中的 plugins
和 presets
,使用如下
#
plugins插件在 Taro 中,一般通过编译配置中的 plugins
字段进行引入。
plugins
字段取值为一个数组,配置方式如下:
#
presets如果你有一系列插件需要配置,而他们通常是组合起来完成特定的事儿,那你可以通过插件集 presets
来进行配置。
配置编译配置中的 presets
字段,如下。
在了解完如何引入插件之后,我们来学习一下如何编写一个插件。
#
如何编写一个插件一个 Taro 的插件都具有固定的代码结构,通常由一个函数组成,示例如下:
插件函数可以接受两个参数:
- ctx:插件当前的运行环境信息,包含插件相关的 API、当前运行参数、辅助方法等等
- options:为插件调用时传入的参数
在插件主体代码部分可以按照自己的需求编写相应代码,通常你可以实现以下功能。
#
Typings建议使用 typescript 来编写插件,这样你就会获得很棒的智能提示,使用方式如下:
#
主要功能#
命令行扩展你可以通过编写插件来为 Taro 拓展命令行的命令,在之前版本的 Taro 中,命令行的命令是固定的,如果你要进行扩展,那你得直接修改 Taro 源码,而如今借助插件功能,你可以任意拓展 Taro 的命令行。
这个功能主要通过 ctx.registerCommand
API 来进行实现,例如,增加一个上传的命令,将编译后的代码上传到服务器:
将这个插件配置到中项目之后,就可以通过 taro upload --remote xxx.xxx.xxx.xxx
命令将编译后代码上传到目标服务器。
#
编译过程扩展同时你也可以通过插件对代码编译过程进行拓展。
正如前面所述,针对编译过程,有 onBuildStart
、onBuildFinish
两个钩子来分别表示编译开始,编译结束,而除此之外也有更多 API 来对编译过程进行修改,如下:
ctx.onBuildStart(() => void)
,编译开始,接收一个回调函数ctx.modifyWebpackChain(args: { chain: any }) => void)
,编译中修改 webpack 配置,在这个钩子中,你可以对 webpackChain 作出想要的调整,等同于配置webpackChain
ctx.modifyBuildAssets(args: { assets: any }) => void)
,修改编译后的结果ctx.modifyBuildTempFileContent(args: { tempFiles: any }) => void)
,修改编译过程中的中间文件,例如修改 app 或页面的 config 配置ctx.onBuildFinish(() => void)
,编译结束,接收一个回调函数
#
编译平台拓展你也可以通过插件功能对编译平台进行拓展。
使用 API ctx.registerPlatform
,Taro 中内置的平台支持都是通过这个 API 来进行实现。
注意:这是未完工的功能,需要依赖代码编译器
@tarojs/transform-wx
的改造完成#
API
通过以上内容,我们已经大致知道 Taro 插件可以实现哪些特性并且可以编写一个简单的 Taro 插件了,但是,为了能够编写更加复杂且标准的插件,我们需要了解 Taro 插件机制中的具体 API 用法。
#
插件环境变量#
ctx.paths包含当前执行命令的相关路径,所有的路径如下(并不是所有命令都会拥有以下所有路径):
ctx.paths.appPath
,当前命令执行的目录,如果是build
命令则为当前项目路径ctx.paths.configPath
,当前项目配置目录,如果init
命令,则没有此路径ctx.paths.sourcePath
,当前项目源码路径ctx.paths.outputPath
,当前项目输出代码路径ctx.paths.nodeModulesPath
,当前项目所用的 node_modules 路径
#
ctx.runOpts获取当前执行命令所带的参数,例如命令 taro upload --remote xxx.xxx.xxx.xxx
,则 ctx.runOpts
值为:
#
ctx.helper为包 @tarojs/helper
的快捷使用方式,包含其所有 API。
#
ctx.initialConfig获取项目配置。
#
ctx.plugins获取当前所有挂载的插件。
#
插件方法Taro 的插件架构基于 Tapable。
#
ctx.register(hook: IHook)注册一个可供其他插件调用的钩子,接收一个参数,即 Hook 对象。
一个Hook 对象类型如下:
通过 ctx.register
注册过的钩子需要通过方法 ctx.applyPlugins
进行触发。
我们约定,按照传入的 Hook 对象的 name
来区分 Hook 类型,主要为以下三类:
- 事件类型 Hook,Hook name 以
on
开头,如onStart
,这种类型的 Hook 只管触发而不关心 Hook 回调 fn 的值,Hook 的回调 fn 接收一个参数opts
,为触发钩子时传入的参数 - 修改类型 Hook,Hook name 以
modify
开头,如modifyBuildAssets
,这种类型的 Hook 触发后会返回做出某项修改后的值,Hook 的回调 fn 接收两个参数opts
和arg
,分别为触发钩子时传入的参数和上一个回调执行的结果 - 添加类型 Hook,Hook name 以
add
开头,如addConfig
,这种类型 Hook 会将所有回调的结果组合成数组最终返回,Hook 的回调 fn 接收两个参数opts
和arg
,分别为触发钩子时传入的参数和上一个回调执行的结果
如果 Hook 对象的 name
不属于以上三类,则该 Hook 表现情况类似事件类型 Hook。
钩子回调可以是异步也可以是同步,同一个 Hook 标识下一系列回调会借助 Tapable 的 AsyncSeriesWaterfallHook 组织为异步串行任务依次执行。
#
ctx.registerMethod(arg: string | { name: string, fn?: Function }, fn?: Function)向 ctx
上挂载一个方法可供其他插件直接调用。
主要调用方式:
其中方法名必须指定,而对于回调函数则存在两种情况。
#
指定回调函数则直接往 ctx
上进行挂载方法,调用时 ctx.methodName
即执行 registerMethod
上指定的回调函数。
#
不指定回调函数则相当于注册了一个 methodName
钩子,与 ctx.register
注册钩子一样需要通过方法 ctx.applyPlugins
进行触发,而具体要执行的钩子回调则通过 ctx.methodName
进行指定,可以指定多个要执行的回调,最后会按照注册顺序依次执行。
内置的编译过程中的 API 如 ctx.onBuildStart
等均是通过这种方式注册。
#
ctx.registerCommand(hook: ICommand)注册一个自定义命令。
使用方式:
#
ctx.registerPlatform(hook: IPlatform)注册一个编译平台。
使用方式:
#
ctx.applyPlugins(args: string | { name: string, initialVal?: any, opts?: any })触发注册的钩子。
传入的钩子名为 ctx.register
和 ctx.registerMethod
指定的名字。
这里值得注意的是如果是修改类型和添加类型的钩子,则拥有返回结果,否则不用关心其返回结果。
使用方式:
#
ctx.addPluginOptsSchema(schema: Function)为插件入参添加校验,接受一个函数类型参数,函数入参为 joi 对象,返回值为 joi schema。
使用方式:
#
ctx.writeFileToDist({ filePath: string, content: string })向编译结果目录中写入文件,参数:
- filePath: 文件放入编译结果目录下的路径
- content: 文件内容
#
ctx.generateFrameworkInfo({ platform: string })生成编译信息文件 .frameworkinfo,参数:
- platform: 平台名
#
ctx.generateProjectConfig({ srcConfigName: string, distConfigName: string })根据当前项目配置,生成最终项目配置,参数:
- srcConfigName: 源码中配置名
- distConfigName: 最终生成的配置名