阅读 registerGenerator UMI 插件

一、前言

在使用 UMI 插件开发命令行功能时，需要使用registerGenerator 这个 API。 UMI 官网 对此做了介绍。

在umi-next里，发现对registerGenerator进行了升级，使用起来更加简洁明了。

那么就来熟悉下registerGenerator的前后使用差异。

二、umi3 下的 registerGenerator

registerGenerator开放两个属性：

• key: 命令行关键字。
• Generator: 自定义的功能实现。

在命令行中键入umi generate <type> <name> [options]。会通过监听对应的key执行Generator下的内容。

以下是Generator内置提供的方法

有了这些方法，能够异步写入模板、写入文件夹、执行提示等操作。

例如想要在业务项目的某个位置创建页面，或者是创建一整个项目，可以通过以下代码来实现：

三、umi-next 下的 registerGenerator

1、使用能力

将Generator替换成以下属性：

• name: 在执行命令行时显示的功能名称
• description: 对功能的详细描述
• type: 1)、enable在执行命令前会先调用checkEnable方法来校验是否满足自定义的环境，若不满足会结束命令，并给出错误提示。2)、generate直接生成
• checkEnable:type为enable时需声明，用来检查是否开启
• fn: 执行命令行的功能，并开放出api、generateFile、installDeps、updatePackageJSON等辅助功能和属性让提高用户体验。

开发者和用户在使用上述的 API 时会对功能描述更加清晰，fn: () => {}开放出来的辅助函数更加便捷。来看以下例子：

2、两者的比较

升级后的registerGenerator增加了命令行执行前的检测能力，减少了误执行命令带来的风险。

fn的函数内置了重复的代码，使代码更加轻便，让开发者集中精力在功能代码上。针对重点功能抛出了辅助函数.

拿generateFile来说，原有的逻辑需要开发者自行判断路径的类型，copy的功能分为copyTpl和copyDirectory。而generateFile对其进行整合，内置了路径类型判断和copy功能。

接下来，就抽丝剥茧般的阅读下这块代码。

3、Generator底层逻辑

在/core/src/service/pluginApi.ts#L81中得知，最终所执行的是Generator类，并将全部参数传递过去。通过this.service.generators[key] = new Generator()保证了每个命令行互不影响，允许多条命令同时执行。

继续点击Generator进入到generator.ts文件，在这个文件下看到了registerGenerator的所有类型定义。

registerGenerator能力的使用，是因为执行了umi generate xxx(简写umi g xxx)。

命令的建立在umi里是使用registerCommand，所以可以通过全局搜索name: 'generate'的代码位置。

不出意外，我们能在/core/src/service/generatePlugin.ts下找到其核心逻辑。

从代码中能够看到type === enable会异步进行checkEnable的校验，若为generate则直接执行。并且在fn()函数中抛出了generateFile、installDeps、updatePackageJSON等函数和属性。

Generator至此告一段落。

4、generateFile底层逻辑

从两个umi版本中可以看出大部分使用registerGenerator的场景都在使用copy能力。因此，generateFile算是核心逻辑。

在packages/utils/src/BaseGenerator就是整个页面生成器的核心。

./BaseGenerator.ts下对path参数做了两层判断。

如果是文件夹类型，则使用copyDirectory进行文件夹的复制。

如果文件后缀为.tpl则使用copyTpl实现模版复制。

剩余内容则通过文件拷贝的功能用fs.copyFileSync(path, absTarget)来实现。