Skip to content

Latest commit

 

History

History
97 lines (66 loc) · 2.18 KB

Scaffold.md

File metadata and controls

97 lines (66 loc) · 2.18 KB

脚手架

  • 脚手架的三个主要组成部分
    • 构建配置
    • 部署配置
    • 测试配置
  • 针对不同类型的应用,脚手架应提供不同的初始模板
    • C 端项目
    • B 端项目
    • 面向组件库
    • node 项目
    • rn 项目
    • ...

脚手架设计的基本原则

  • 脚手架本身是一份代码,需要按版本管理
  • 脚手架本身是一个服务,而不是模板,只对外提供接口。可通过升级版本更新脚手架
  • 脚手架的扩展机制:插件、勾子函数等

脚手架包含的内容

通用

  • 命令
  • 配置文件
  • 资源处理
    • 寻址、编译、压缩、打包
    • 特定资源的特殊处理(如 inline、spite)
  • 模板构建
  • 环境变量
  • lint 配置

开发

  • devserver 服务器(代理、热更)
  • debug 调试(日志)

测试

  • 集成测试框架

上线

  • 生产环境构建
  • checklist 各校验环节配置
  • 上线脚本配置

除了通用脚手架,还应该考虑什么

开发相关

  • 格式规范
  • 目录结构规范
  • 路径 alias
  • 公共基础库(桥、组件、utils、第三方库如 date-fns 等)
  • 业务公共方法封装
    • 网络请求
    • 页面跳转
    • 登录鉴权
    • ...
  • 布局适配方案(自适应、异形屏、基础布局...)
  • 环境配置(根据环境变量配置不同的域名)
  • 存储方案
  • polyfill 方案
  • 公共样式(normalize、hairline、variables、mixins...)
  • 全局配置

基础服务

  • 接入部署服务
  • 接入埋点
  • 接入桥环境
  • 接入前端监控
  • 接入日志
  • 按需接入体验优化方案(例如骨架屏、前端离线等)
  • 按需接入容器层提供的技术方案(例如离线化、预加载等)

制定了标准,如何约束

如何约束开发者复用公共模块中已有的方法,而不是重新造一个?

lint-a-specific-variable-name-with-eslint

如何限制函数的复杂度,避免逻辑在后续迭代中失控式膨胀?

eslint complexity

如何约束目录结构?