日常开发中，工程化往往在项目初期完成（通过脚手架完成），资历尚浅的工程师（比如我）可能感知不到，比如我所在的公司就把webpack配置写在了脚手架里，项目模版并没有引入配置文件，所以日常开发中只需要使用package.json里scripts的命令就可以直接操作webpack，进行打包构建，具体的配置项，做了那些处理都是无痛感知的。为了有更好的前途（升职加薪），在这里记录下我对前端工程化的认识。
首先要对“前端工程化”有个大体的印象
作为一名小白程序员，相信大多数时间是忙于做业务的，从一个项目做到下一个项目，如果有一天你开始参与一个新项目发现同样是后台项目（管理类平台），它和你之前做的项目目录结构、eslint规则等都不一样那一定是比较痛苦的一件事情，同类型项目，风格截然不同。此时你会认识到，原来统一的标准规则是挺重要的一件事情。所以从公司团队角度，前端工程化是一个标准化过程，所有的项目都有共同的起点，通过制定脚手架（一般区分前后台项目），内置webpack、mock服务、开发规范（eslint）、单元测试等功能，约束每个项目的模样、玩法大体一样。总结就是将前端开发流程，标准化、规范化、工具化、自动化、简单化，提升了应用质量及开发效率。
前端工程化具体包含哪些知识
- 脚手架
- 构建工具（webpack）
- MOCK服务
- 开发规范
- 单元测试
- 项目部署
这里就不铺开说了，重点记录下“脚手架”和“构建工具”
脚手架
在说脚手架之前，我们先来回顾下从0接手一个新项目时你做了哪些操作。先看项目类型，前台（H5、小程序等面向C端（用户））、中后台（各种管理后台），然后找对应的脚手架，以我们公司开源的后台脚手架为例，打开终端执行npx autos init（npx命令可以执行未下载的包，就是默认安装再执行）后会看到有交互信息，按照需要巴巴一顿操作下来，项目模版就搞下来了，项目就从0到有了，简直不要太爽。然后就进入到了你熟悉的阶段，建路由开撸代码。
稍等片刻
项目模版
可以看出，一个合格的脚手架在项目初期十分好用，好的开始是成功的一半，那么问题来了，一个合格的脚手架又包含那些功能呢？
- 通用的项目目录模版
- 通用的Webpack配置
- 统一的Eslint校验规则
- 统一的单元测试框架配置：单元测试覆盖率、测试的目录等
- 统一的Dockerfile和jenkinsfile (用来打包成镜像和部署流水线定义)
- 统一babel的配置（.babelrc或babel.config.js）
- 统一的常量配置（缓存字段等等）
- 不同环境的配置文件（development、test、production）
（以上为理想状态，具体按照团队需要）
到这里对脚手架已经有个初步认识了，下面我们看看如何实现一个简易脚手架。
如何开发脚手架
创建一个文件夹，做为脚手架的起点，执行npm init生成package.json文件
工欲善其事必先利其器，安装以下npm包
- 可用于控制台选择的工具：inquirer(交互、选择)
- 可处理控制台命令的工具：commander（定义脚手架命令）
- download-git-repo：下载远程模板工具，负责下载远程仓库的模板项目
- 可改变输出log颜色的工具：chalk
- 可执行shell命令的工具: child_process
inquirer可以实现脚手架的交互功能，比如上图利用脚手架初始化项目时的问询，还可以选择使用js还是ts等场景的问询，inquire会记录用户的选择结果，从而根据用户需要完成一些定制化的需求。
commander定义脚手架命令，好比是package.json里的script方法，一般有init、dev、build等命令。 具体实操可以借鉴 juejin.cn/post/684490…
