从 Angular转到 React，网易严选的前端工程化实践( 二 ) 前端日益发展

4、项目生命周期
项目生命周期，就是指项目从初始化，到开发（或后期迭代），再到 CICD 的这么一个周期。可以看到下一层的命令大多都可以对应到项目生命周期中，例如：

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

通过这整个架构可以看到，我们的工具可以介入到项目生命周期里的所有环节，那么这些环节有的一些问题和痛点，也可以通过工具去解决。下面将会从项目生命周期的角度讲解一下我们工程化的一个具体方案。
项目初始化首先，在项目初始化过程中需要解决的一个问题就是：帮助规范落地。
把规范分为项目规范和流程规范，流程规范上面也介绍了，通过工具做了一个约束，那么项目规范怎么在初始化的时候落地呢？
我们的做法是，将这部分规范落地到模板当中，用户通过 @sharkr/cli 去 init 项目，选择合适的模板， 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 版本中新增的命令，它能临时下载一个模块并且运行它，运行之后再删除这个模块。

文章插图

用户执行 sr init myapp ，调用 @sharkr/cli
@sharkr/cli 使用 npx 调用最新的 init 插件处理

通过方案二，可以看到使用 npx 的方式调用插件，可以使用户在任何时候使用 init 命令都能调用最新的 init 插件完成项目初始化。
说完了项目初始化，再来看一下开发 / 迭代过程中会遇到哪些问题。
开发 / 迭代完成项目初始化进入开发阶段，这个阶段应该是关注业务本身、减少重复工作、高效快速的。
1、dev 环境
开始项目开发遇到的第一个问题就是 dev 环境。需要 webpack 配置编译代码、需要一个本地 server、需要一个数据转发、需要 eslint 配置规范编码等。
这一部分可以通过 @sharkr/scripts 提供 webpack 配置和 server 脚本，在模板里集成调用，用 koa 起一个本地服务， koa 中间件完成转发等。 @sharkr/eslint-config-react 定义编码规范。在这个环节规范了流程和配置，有效的保障项目质量。
有了一个完备的 dev 环境，再来看一下前面说到的资源复用和资源 / 项目升级。
2、资源复用和资源 / 项目升级
资源复用
简单把资源分为两类，一类是有固定输入输出，可抽离的，例如时间控件，下拉列表等；还有一类是无固定输入输出，不可抽离，但是又具有某些共性的，例如 B 端常见的列表页、详情页，这一部分资源没有一个很好的复用方式。
对于第一类资源，可以采用封装组件的形式完成资源共享：