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 %>

你可能感兴趣的:(前端,脚手架,webpack,node.js)