InfoQ科技从 Angular转到 React，网易严选的前端工程化实践( 二 )

@sharkr/eslint-config-react 插件提供 eslint 检查；

还有一部分公共能力封装成 util 插件，方便共享。

这种插件的方式可以使工具具有很强的扩展性，在跟其他团队共建时，可以很方便的做一些自定义，但是又符合统一的规范。
3、统一命令层
第三层是统一命令层，这一层做的事情就是，最终对用户暴露一个统一的工具 @sharkr/cli，在 cli 里去规范常用的一些命令，当然这些命令的具体实现都是调用下一层的插件。这些命令会应用到项目开发的生命周期中去。
在这一层中会添加埋点，用于收集命令、项目、使用包等相关情况，以便做数据的统计与分析，了解实际落地情况，也为未来迭代版本提供有效参考。
4、项目生命周期
项目生命周期，就是指项目从初始化，到开发（或后期迭代），再到 CICD 的这么一个周期。可以看到下一层的命令大多都可以对应到项目生命周期中，例如：

init 完成项目初始化
dev 可以使开发者快速的进入开发
add 可以给项目增加一个资源
generate 可以执行资源里定义的命令
update 帮助快速升级资源
lint 编码规范校验
test 对开发过程中的代码做一个测试
build 在 CI 阶段可以帮助完成编译打包

通过这整个架构可以看到，我们的工具可以介入到项目生命周期里的所有环节，那么这些环节有的一些问题和痛点，也可以通过工具去解决。下面将会从项目生命周期的角度讲解一下我们工程化的一个具体方案。
首先，在项目初始化过程中需要解决的一个问题就是：帮助规范落地。
把规范分为项目规范和流程规范，流程规范上面也介绍了，通过工具做了一个约束，那么项目规范怎么在初始化的时候落地呢？
我们的做法是，将这部分规范落地到模板当中，用户通过 @sharkr/cli 去 init 项目，选择合适的模板， init 插件完成模板处理，然后就初始化了一个符合规范的项目。
这里提到选择合适模板， init 插件完成模板处理，那 init 插件是怎么做的呢？
每个团队都会有一些常用的业务场景，例如我们 B 端，会维护好几个模板，纯 web 的、带 node server 的、应用于微应用的，那么这一系列模板作为一个集合，配套的会出一个相应的 init 插件，这个插件可以完成这系列模板的初始化处理。
执行 init 命令时， cli 调用对应的 init 插件，用户根据提示输入项目相关配置项， init 插件根据配置项处理模板。
假如说其他团队也有自己的模板，那么同样的，他们也可以根据规范提供模板配套的 init 插件供 cli 调用，方便共建。
这是插件的一个优势，可以方便扩展自定义的部分，但是它也带来了一个小问题。这部分插件不是很稳定，可能经常需要更新，它的频繁更新会给用户带来影响。这就需要有一个较好的插件更新机制，方便迭代。
插件更新
先来看一下最初采用的插件更新机制，如下图：

本文插图

用户执行 sr init myapp ，调用 @sharkr/cli
@sharkr/cli 检查 init 插件版本
发现版本不是最新的，提示用户 update @sharkr/cli
用户全局 update @sharkr/cli
再次执行 sr init myapp, 调用 @sharkr/cli
@sharkr/cli 调用最新的 init 处理

这种方式需要用户经常手动更新，不是很友好，所以在后来方案设计时，改用了 npx 的方式调用 init 插件。
npx 是 npm5.2 版本中新增的命令，它能临时下载一个模块并且运行它，运行之后再删除这个模块。