multiple-version(简称:mv)是一个 veronica(1.x) 项目模板,用于搭建大型的企业级项目前端
mv 中的应用层次结构,处于最顶端的容纳整个前端项目的容器叫做产品, 产品包含多个项目或版本。具体到项目内部,一个前端项目包含一个或多个应用(即单页面), 每个应用包含若干个功能模块,模块包含许多不同的组件
-
root \ 网站根目录
- bower_components\ 包管理工具维护的三方库
- node_modules\ 包管理工具维护的三方库
- www\ 前端产品根目录
-
www\ 产品根目录
- assets\ 自己管理的三方库(多个项目共用)
- product\ 主干版本目录
- xxxx(eg: custom-version-1)\ 定制版本目录
主干版本与定制版本
通常我们需要维护许多个版本的前端代码,一种方式是依赖版本控制工具(例如:Git)来维护, 而在 mv 中,我们不仅通过这种方式,同时从应用程序架构层面就区分了版本,代码严格隔离,这样能够灵活的进行切换和组合,各定制版本只需维护定制的部分代码,能够较好的进行复用
主干版本和定制版本的目录结构完全一致,不同点在于,定制版本只建它定制部分的目录和文件,同时定制的文件需要依赖它所定制的文件,并在原有版本的基础上进行定制或扩展
另一种用法是将版本目录当成项目目录来用,因此 www 下就可以放各个项目,理论上来讲可以把你做的所有项目都放在这个目录里,如果项目间有依赖也可以参照版本目录模式来管理
虽然开发时是把所有项目的代码放到一个大目录来管理,但最终运行的代码是构建过后的,因此上线运行的代码是该代码库的一个子级,这取决于你具体的构建文件配置,你可以使用多个构建文件,这样就能同时维护多个线上版本
下面是某个版本(如:product、custom-version...)内的目录结构
- xxx\
- app\ 该版本内的应用
- modules\ 功能模块目录
- content\ 资源目录,放置公共的样式表和图片及其他资源
- build\ 构建目录,放置运行时和打包构建时的相关配置文件
- assets\ 该版本所管理的第三方库
- app\
- _common\ 多个应用共用的文件
- xxxx \ 单个应用文件夹(eg: home, manager...),每个应用就是一张页面或一个 SPA(单页应用)
- modules\
- xxxx(module)\
- configs\ 放置该模块的配置文件
- meta.js 模块元数据文件(必须)
- backendApi.js 后台接口描述文件
- model.js 数据模型文件
- page.js 路由页面配置文件
- extension.js 扩展配置文件
- ...
- extensions\ 该模块对应用的扩展
- widgets\ 该模块下的界面组件
- configs\ 放置该模块的配置文件
- yyyy(module)\
- xxxx(module)\
widgets 目录
所有的组件都应该使用全局唯一名称,但默认会加上模块名称作为前缀,这里有两种放置方式: 单级目录和多层级目录,单级目录意味着该模块下的所有组件放置同级目录,因此需要取一个长名称以避免冲突, 而采用多层级目录则按照层级来约束,框架在识别是会自动将层级关系拼接成唯一名称,例如可按照如下的分类方式:
- widgets
- 业务类型
- 组件类型
- 组件
- 组件类型
- 业务类型
其中,业务类型是从业务角度进行分类,例如用于总体框架的组件:frame,用于数据管理类型的组件:manage,而组件类型则按照界面功能角度进行分类,并使用通用的语义以便更好的组织 并快速定位,一些通用的类型举例:
- nav:导航类
- list:列表类
- detail: 详情类
- form:表单类
- view:呈现类
构建采用的是 grunt-veronica 插件,每个项目有自己独立的构建文件,构建是该项目模板比较重要的过程,一定要合理编写构建配置文件pack-conf.js
,以达到集中式开发,多版本发布的目的,
构建过程如下图所示: