2020成绩单:前端脚手架的开发思路与实现

在一个小公司最大的好处是什么都要搞，PC/公众号/小程序，前台，后台，中台，react，vue、UI都接触，产品需求不断，项目越做越多，人还是那几个。对于前端的标准化，工程化的要求越来越高。

aotoo-hub作为一套通用型前端脚手架，无技术栈依赖，聚焦于多人协作及工程化。可以帮助开发者快速产出项目，喜欢折腾的可以研究下。

aotoo-hub是一套前端/NODE 端一体化设计的全栈脚手架，前端使用webpack4编译，node端使用koa2提供服务。hub可独立运行作为前端编译工具，也可配合node端部署线上服务

独立运行时，仅作为前端编译、输出静态资源工具，hub采用webpack对前端的资源进行编译，开发模式下由webpack-dev-server提供热更新支持，生产环境下仅产出压缩后的代码

融合运行时，node(koa2，koa-router)将接管webpack-dev-server提供后端服务，此时可实现SSR服务，API服务，可用于部署，提供线上服务

一些特点

• 提供简单的命令行工具
• 编译环境支持多项目，共享编译资源及node_module
• 支持为React/Vue/Jq/原生js/小程序等项目提供编译环境
• 规范的前端、node端目录结构
• 支持动态样式(sass/stylus)
• 支持多环境，命令行切换测试，生产等环境
• 支持node端(koa2)

脚手架源码结构

hub工作空间
  ├── build
  ├── aotoo.config.js
  ├── index.js
  ├── package.json
  ├── postcss.config.js
  └── src
       # vue 项目演示
       └─ vueSample
             ├── configs # node环境配置文件，默认包含default.js
             ├── dist      # 静态资源输出目录
             ├── js        # 前端业务js目录(前端)
                 │── venders # 第三方库文件目录+自定义公共库(前端)
                 ...
             └── server    # node端的源码目录
                   │── pages  # node端的业务目录
                   └── plugins # 自定义插件目录
                   
       # react 项目演示
       └─ reactSample
             ├── configs # node环境配置文件，默认包含default.js
             ├── dist      # 静态资源输出目录
             ├── js        # 前端业务js目录(前端)
                 │── venders # 第三方库文件目录+自定义公共库(前端)
                 ...
             └── server    # node端的源码目录
                   │── pages  # node端的业务目录
                   └── plugins # 自定义插件目录
                   
       # 小程序项目演示
       └─ xcxSample 
             ...
             ...
             
       # 文档项目演示
       └─ mdSample 
             ...
             ...

GITHUB
更多说明

hub脚手架开发的一些思路

前端项目架构比后端项目架构更具有挑战性，为啥呢？一般后端架构(大部分中小项目)稳定在一个环境，语言，项目下，可能几年更新一次，而前端要应对多端输出，项目繁杂，多种框架，复杂组件等等情况，框架的更新还特别活跃，经常有学不动想放弃的感觉。

脚手架作为一个重要前端工具，特别需要有统一的，标准化的思想。好的脚手架能够能让开发，测试、运维的工作变得很爽。我们需要脚手架能约束、规范工程项目结构；有统一的编译环境；与项目去耦合；方便进行多人协作；还应该要简单，开箱即用，开发者只需关注业务，在生成的项目结构的基础上进行开发即可

与项目解耦

为什么需要将架构与项目去耦合，试想下，当一个公司存在n个项目时，架构师更新、维护不同项目，不同框架的脚手架，造成项目不稳定的风险，同时增加了架构师、开发人员、测试人员、运维人员，运营人员的时间成本，沟通成本。

技术栈无关

公司项目类型很多，轻量，且需要快速迭代上线的项目，一般我们用vue；比较复杂，由多人协作共同完成的项目。一般我们用react；小程序也是前端的热门方向，还有老旧基于jq项目，因此脚手架需要能够支持编译多种前端框架

这个不是很难，在webpack中添加各种框架所需的配置就可以实现，hub目前支持React、Vue、Angular、Jquery、小程序等技术栈。

多项目支持

架构与项目去耦合，即可单个项目独立编译运行，又可以同时运行。所有项目共享hub工作空间的编译环境，共享工作空间的node_module。项目自有dist目录，启动时有分配唯一服务端口。如下图所示

工作空间
  ├── build
  └── src
       └─ vueSample
             └─ dist
       └─ reactSample
                └─ dist
       └─ mdSample
             └─ dist
       └─ xcxSample
             └─ dist

命令行工具

命令行需要简洁高效，能够实现环境初始化、项目初始化、开发模式、生产模式，环境切换，可以传递参数，支持一键部署

配置化

命令行、配置文件相辅相成，一个都不能少，配置能够简化命令行操作，比如需要同时启动多项目，设置某项目的环境等。

下例是hub项目的具体配置项

{
  // 项目名称
  name: 'mdSample', 

  // 指定项目版本
  version: 1.0.8,  

  // 是否启动项目，默认false
  // 启动时，可简化命令行输入项目名称
  startup: true,    

  // 是否启动node server，默认false，由webpack-dev-server提供服务
  // 如在组件开发过程中，关闭node服务，提升性能和效率
  server: false, 

  // 省略前端编译，默认false，需要设置server=true
  // 只启动node端，开发模式提升效率，生产模式可直接部署
  onlynode: false, 

  // 项目源码目录
  src: path.join(ROOT, 'src/mdSample'),  

  // 指定项目端口，不指定则分配随机端口
  port: 8400,

  options: {

    // 项目灰度环境，如测试，预发布，生产等
    // 建议使用命令行 --config test，选择环境配置
    // scenes: 'default' 
  }
},

版本管理

环境与项目隔离

隔离是为了更专注，各司其职，架构师更新环境，开发人员更新业务，互不干扰，编译环境与项目去耦合。使用git能够很方便的实现这一设想，如下图

工作空间  # ==> 设置环境git，忽略src/*
  ├── build
  └── src 
       └─ vueSample # ==> 设置项目git

在使得命令行工具可以支持在项目源码目录中执行，开发人员使用vscode仅仅打开vueSample目录就可以心无旁骛的开始开发工作。

# 在hub工作空间目录下  
aotoo dev vueSample # 运行开发环境

# 在项目vueSample目录下
cd src/vueSample
aotoo dev vueSample # 在项目源码目录中也可以启动开发环境

项目版本
项目版本基于配置文件的version，项目的静态资源会被全部编译至dist/${version}目录，多个版本就会存在多个目录，方便回滚，备份等等保险操作，如下图

├─ dist          # 输出目录(前端)
    │─ 1.0.1     # 版本目录，依据配置中的version字段
    └─ 1.0.8
        └─ dev # 开发目录
            │── js/index.js
            │── html/index.html
             ...

多环境

test1环境，test2环境，test3环境...，脚手架通过命令行参数指定项目当前运行时环境配置，也可以设置配置文件来切换。

现在很多公司都用到了apollo这样的云配置中心，这对于开发者来说非常不方便，有两种方案可以考虑，一是使用命令行传递不同参数，使项目调用云配置或者本地配置；二是在项目初始化时，在配置文件中创建方法去自动抓取云配置。

aotoo dev --config test1

规范项目目录

设计合理、规范、灵活的模板对于项目结构的合理性非常有好处，因为我们都围绕模板来建立目录，产出资源，而任何资源最终都被用在模板上。

模板的静态资源

 
  
  
 
 
 
<%- root %>