5分钟看懂 | 从工程化角度出发的脚手架开源工具-京东云开发者社区

前端脚手架的由来

前端脚手架是伴随着业务复杂度提升而来的提效工具。

在团队规模小或者业务比较简单的时候，项目的初始化往往是直接从一个已有的项目中拷贝出来，根据情况删掉一部分代码（之前业务强相关的或者不需要的功能等），再修修补补一部分，即可开始新的开发。

随着业务发展，几个人之间的拷贝已经不能满足需要（拷贝的源头无法追溯，出了问题也不知道是哪个版本的问题），项目初始化也变成了把这个模板代码放在 git 仓库中维护起来，需要新建项目时，将代码克隆下来，删除 .git 目录，再重新上传到新项目的仓库。

伴随着业务的复杂度上升，模板代码的仓库也变得多了起来，在新建一个项目时，开发人员不仅要在众多仓库中找到应该克隆哪个仓库，还需要每次都走一遍流程：克隆代码 → 删除.git目录 → 关联并 push 到新仓库，为了提高效率，开发将这个过程封装成 CLI 命令，如 fe-cli，在新建项目时仅需执行fe-cli projectName即可。

前端脚手架的现状

在前端开发的流程中，一个典型的开发流程大概是这样的：

脚手架的作用仅存在于第一步，在初始化后的每一步骤中，全部是由开发自定义的（通常是小组或团队内部的规范）：使用什么方式构建，使用哪个测试工具，代码 lint 的标准，部署时如何审批等等。即便是小范围的内部规范，在不同的项目内，也有可能存在差异。

不仅如此，脚手架通常存在于内部的小团队内，这些脚手架提供的模板即便是非常优秀，也往往局限在内部，无法被其他团队发现和使用，导致只能做到团队内部的提效，无法在团队、部门甚至公司层面做到复用和标准化。

上述的是老团队的情况，而对于一个新组建的团队来说，在繁重业务开发中想要抽取人力去开发一个脚手架往往是有心无力的，团队内的初始化可能又回到了复制粘贴的时代。

leo提供的解决方案

针对上述痛点，我们的团队在调研并收集开发同学意见后，开发了leo脚手架作为解决方案，如下图所示，各团队内部相互闭塞的开发改为由leo统一提供服务，团队内部不仅降低了维护自己脚手架的成本，还可以享受到其他团队提供的服务。

零成本接入

无论是新团队接入，还是老团队将就有项目模板迁移，仅需使用leo init template初始化出一个模板文件，将自己的模板项目移入template文件夹中并推送到远端（在初始化时，leo会在template市场中自动创建并关联项目）。推送后，就可以通过leo init your-template-name来初始化你的模板了。

覆盖开发全链路

不同于过去脚手架仅在初始化中发挥作用，leo通过模块化的设计，使得指令覆盖于开发的全链路当中。

在开发的每个流程中，都可以使用官方或者自定义的工具来支持当前流程的功能，以开发调试为例，官方提供了react-builder作为默认的构建工具，但是如果你使用的是gulp，rollup等其他构建工具，可以通过编写一个builder来支持项目的构建流程（与模板接入相同，仅需初始化后写入构建功能并推送即可）。

leo市场

在上述接入的描述中你可能已经发现，在初始化一个模板或者builder文件时，leo会同时将这个项目同步到对应市场中，从前仅在团队内部使用的模板与构建功能将会服务于更多的leo使用者。