腾讯IVWEB前端工程化工具feflow思考与实践

本篇文章主要介绍腾讯IVWEB团队从0到1在工程化的思考和实践。feflow的全称是Front-end flow（前端工做流），致力于提高研发效率和规范的工程化解决方案。愿景是经过feflow，可使项目建立、开发、构建、规范检查到最终项目上线的整个过程更加自动化和标准化。

要解决的问题

• 项目的目录结构按约定生成
• 团队有一套开发规范进行约束
• 支持多种类型的构建，包括Fis构建和webpack构建
• 团队内部的代码贡献统计、离线包内置App等

为了解决上述问题，咱们于17年2月底开始投入工程化feflow工具的开发和相关规范的制定，目前已经研发出了 feflow 的 CLI 版本，后续会推出 GUI 版本。

架构设计

为了让 feflow 的具备高可扩展性，咱们设计了4层结构，分别是：插件生态、内核层、参数解析器和控制台。除了贯穿整个开发工做流的基础命令选择经过内部插件内置在CLI 的Core里面，其它非必要命令统一经过插件机制进行扩展。

另外一方面，为了使得 feflow 可以适用多种类型的项目。咱们开发了多种类型的业务脚手架，如：活动模板、App H5模板、RN模板和业务组件模板。

执行过程

当用户在控制台里面输入某个命令。首先会经过CLI 的参数解析器，将这个命令解析成一个object对象，而后传递给CLI 的内核。全部的命令都是经过内核上下文提供的 register 函数 进行注册的，一方面内核自身会读取内置插件 注册的基础命令，另外一方面，内核会读取本地已经安装的外部插件注册的命令。若是找到用户输入的命令则开始执行命令对应的回调函数。

基础命令设计

# 初始化项目
$ feflow init

# 本地开发
$ feflow dev

# 代码质量检查
$ feflow lint

# 打包构建
$ feflow build

# 代码发布
$ feflow publish

# 安装插件、脚手架等
$ feflow install package

# 配置本地客户端，如: npm 的源和 proxy
$ feflow config <key> <value>

前面提到，CLI 的命令包含两部分，分别是内置在内核里的基础命令和外部插件提供的命令。那么外部插件要如何设计呢？

插件机制设计

插件实现原理

这里有一个很是巧妙的设计，经过使用node提供的module和vm模块，能够通注入feflow全局变量来访问到cli的实例。从而可以访问cli上的各类属性，好比config, log和一些helper等。

loadPlugin(path, callback) {
    const self = this;

    return fs.readFile(path).then((script) => {

      const module = new Module(path);
      module.filename = path;
      module.paths = Module._nodeModulePaths(path);

      function require(path) {
          return module.require(path);
      }

      require.resolve = function(request) {
          return Module._resolveFilename(request, module);
      };

      require.main = process.mainModule;
      require.extensions = Module._extensions;
      require.cache = Module._cache;

      // Inject feflow variable
      script = '(function(exports, require, module, __filename, __dirname, feflow){' +
          script + '});';

      const fn = vm.runInThisContext(script, path);

      return fn(module.exports, require, module, path, pathFn.dirname(path), self);
      }).asCallback(callback);
  }

命令注册：

命令须要以feflow.cmd.register进行注册，好比：

feflow.cmd.register('deps', 'Config ivweb dependencies', function(args) {
    console.log(args);
    // Plugin logic here.
});

说明：

• register有3个参数，第一个是子命令名称，第二个是命令描述说明信息，第三个是对应的子命令执行逻辑函数。
• feflow会将命令行参数args解析成Object对象，传递给插件处理函数

配置

能够经过feflow.version获取当前feflow的版本，feflow.baseDir 获取feflow跟目录（在用户目录下的.feflow），经过feflow.pluginDir 获取插件目录

日志

经过feflow.log来进行相关命令行日志输出

const log = feflow.log;
log.info()    // 提示日志，控制台中显示绿色
log.debug()   // 调试日志,  命令行增长--debug能够开启，控制台中显示灰色
log.warn()    // 警告日志，控制台中显示黄色背景
log.error()   // 错误日志，控制台中显示红色
log.fatal()   // 致命错误日志，，控制台中显示红色

安装

插件开发完成后，能够经过 feflow 提供的 install 命令安装插件。安装的插件会放置在本地客户端 ~/.feflow/node_modules 文件夹下，而且写入到 ~/.feflow/package.json 中

$ feflow install feflow-plugin-xxx   // 安装某个插件

以后每次运行命令时，便会从本地加载插件所注册的命令

全量更新和增量更新

当CLI发布了一个新的版本，可能咱们会废弃掉某些功能或者提供了新功能。这个时候若是用户依然使用的是旧版本，因为某些服务已经废弃掉了则会报错。在这种新旧版本不兼容的状况下，如何强制用户进行CLI的升级呢？须要在运行命令以前检查本地的CLI是否和远程提供的新版本是否兼容。在新旧版本不兼容时，会强制全量更新。如何判断当前用户安装的本地版本和远程最新版本是否兼容呢？

这里很是巧妙的运用了一下 npm 的 registry机制，每次发布新版本，咱们会在 package.json 里面新增一个自定义字段 compatibleVersion，它的值是一个 semver 的版本号。本地检查时，会读取本地已经安装的版本和远程最新的版本进行比较，看看是否知足 compatibleVersion 的要求。若是不知足，则会自动运行 npm install feflow-cli 到最新的版本。

"configs": {
    "compatibleVersion": ">=0.13.0"
 },

对于插件，采起的是增量更新机制。每一个发布到 npm 上的插件的package.json 中一样会有上面的这个字段，对于本地安装的不兼容的插件列表，会采起增量更新。

多类型脚手架的架构设计

项目拷贝存在的问题显而易见，大体有如下三个方面：

• 容易出错；一旦某个关键文件拷贝丢失或者错误，极可能须要耗费半天到一天的时间排查环境问题。
• 不一样场景下对目录结构要求不一样；平时开发过程当中，工程一般会分为运营活动、Hybrid业务、入口级别的项目（对性能和体验有极致和苛刻的要求）。须要基于RN或者Node.js的首屏直出，还有经常使用的业务组件等的开发。
• 新的Feature和BugFix难以同步；某个同窗开发过程当中增长的新方法或者解决的bug很难传递给其它同窗而且沉淀成经验积累下来。

社区里面提供了完美的Yeoman解决方案，它是为了自动化项目的建立而生。Yeoman建立项目包括如下几个阶段：

• initializing: 初始化一些状态之类的，一般是和用户输入的 options 或者 arguments 打交道
• prompting: 和用户交互的时候（命令行问答之类的）调用
• configuring: 保存配置文件（如 .babelrc 等）
• writing: 生成模板文件
• install: 安装依赖
• end: 结束部分，初始代码自动提交

咱们只须要继承Yeoman的Generator类作模板定制化，基于Yeoman的脚手架设计思路应该以下图所示：

当开发者输入 feflow init 命令时，开发者会告诉CLI须要建立哪种类型的项目，CLI收到命令后。从本地已经安装的Yeoman脚手架里面选择某种类型的模板。而后，CLI会调用Gitlab API在远程建立仓库而且授予开发者master权限。接下来，会根据实际业务场景须要，自动化申请一些打点信息，常见的如离线包id，监控告警id等等。以后，在本地目录生成代码而且安装项目依赖的npm包，最后将本次初始化生成的全部代码自动提交到远程Git仓库。

多类型主流构建支持

为了让feflow 支持多种类型的构建环境，好比 Fis3 和 webpack，或者前不久刚推出的号称零配置成本的 Parcel 构建。在每一个项目的跟目录会放置一份配置文件，名称为 feflow.json。它的配置多是这样的：

{
    "builderType": "builder-webpack3",
    "builderOptions": {
        "moduleName": "mobile",
        "bizName": "category",
        "minifyHTML": true,
        "minifyCSS": true,
        "minifyJS": true,
        "usePx2rem": true,
        "remUnit": 100,
        "remPrecision": 8,
        "inject": true,
        "port": 8001
    }
}

builderType为构建的npm包，builderOptions为构建的参数配置。

最后

腾讯IVWEB团队的工程化解决方案feflow已经开源：Github主页：https://github.com/feflow/feflow

若是对您的团队或者项目有帮助，请给个Star支持一下哈～