约定大于配置的Vue前端基座式脚手架，可以认为是一套整合的方案，提供一个前端“最佳实践”的组合配置。开发者需要的就是在这套架构的约束下填充自己的页面与业务代码。
vue有着渲染性能高、开发速度快、全功能配置的三大特点，相比angular定制型强，相比react开发速度快，如果不对vue做一定规范，在大型企业级单页应用中并不突出，该项目约定目录与实现方式，通过“约定大于配置”的方式，在约束下填充不同的页面与业务代码，提升维护性、便捷性、可靠性，有效弥补了普通vue的缺陷。目前功能包括：
- 目录约定：强制的不同功能的目录约定。
- http拦截：对状态码和错误码先行判断和处理，避免项目中判断逻辑过多
- 与restful一致的统一api定义：对增删查改按照名词添加基类，抽离出所有接口作为接口工厂处处以函数方式调用，避免接口修改后所有用到该接口代码都需修改的场景
- 公共方法（已含有加解密、防抖、节流等常用库）：抽离公共函数被各处调用，只需要维护一个函数，添加crypo、lodash、moment等常用函数库方便开发
- 混入模块：作为对面向对象的补充存在，混入的方式可以让组件中公共内容得到抽离
- 公共常量：抽离公共常量，提升可读性，方便常量的维护，有效避免常量修改后需要到处该的问题
- 权限管理：添加路由级与按钮级的权限管理功能
- 环境变量：添加dev、st、uat、prod四套基本环节变量，并且绑定不同的启动命令，一个应用本身应该是无状态的，并拥有根据运行环境设置自身的能力
- 路由拆分：把路由按照二级路由为一个文件做了拆分，避免路由文件过长而维护不方便 具体的功能请看源代码及其注释，注释详尽解释了各个文件与方法的作用。
- docker/nginx支持: 可以直接启动一个nginx容器的服务器，最大化在本地模拟服务端环境
优化项：
- 按需加载：使用webpack按需加载打包，减少包体积
- 打包优化：优化webpack打包，极致的打包速度，飞一般的开发体验
- chunk拆分：按照路由拆分webpack chunk，并且将login与dashboard等最先被用户看到的代码优先加载
未来计划的工作：
- 单元测试
- 端对端测试
版本依赖：node>=10.17及其对应的npm（未测试较低版本，理论上上低版本也应该可行） 命令行工具项目地址：https://github.com/rhythm1995/libra-cli
# 安装命令行工具
$ npm install -g libra-create
# 生成项目
$ libra-cli init demo
# 安装依赖
$ cd demo && yarn
# 运行开发环境，项目会启动在8080端口
$ npm run dev# 打包项目，项目会被打包到dist目录下
$ npm run build# 在docker下运行项目
$ npm run docker.
├── CODESTYLE.md（代码风格文档）
├── GITFLOW.md（工作流文档）
├── LICENSE
├── README.md（项目必读文档）
├── assets（文档中用到的静态资源）
├── babel.config.js（babel配置）
├── package.json
├── postcss.config.js（css预编译配置）
├── public
│ └── index.html
├── src（源码）
│ ├── App.vue（入口vue）
│ ├── api（api封装）
│ │ ├── BaseApi.js（api基类）
│ │ ├── UserApi.js（用户API类）
│ │ └── index.js
│ ├── assets（静态资源）
│ │ ├── css
│ │ └── img
│ ├── common（一些可选用模块）
│ │ ├── bus.js（全局bus通信）
│ │ └── directives.js（自定义指令）
│ ├── components（公共组件）
│ ├── main.js（入口）
│ ├── page（路由页面）
│ ├── public（公共）
│ │ ├── constant.js（常量）
│ │ ├── help.js（辅助函数）
│ │ └── storage.js（storage存储）
│ │ └── request.js（axios二次封装）
│ ├── store（vuex状态管理）
│ └── router（路由）
│ │ ├── home.js（home的路由）
│ │ └── index.js
├── .env.dev（dev环境变量）
├── .env.prod（prod环境变量）
├── .env.st（st环境变量）
├── .env.uat（uat环境变量）
├── vue.config.js（vue-cli配置）
└── yarn.lock
参考代码规范指南 希望尽量按照这个规范
一共有以下几种分支：
- master——最为稳定功能最为完整的随时可发布的代码；
- hotfix——修复线上代码的 bug；
- feature——某个功能点正在开发阶段；
- release——发布定期要上线的功能。
其中「master」和「develop」是「主要分支」，其他的分支是基于它们派生出来的。主要分支每种类型只能有一个，派生分支每个类型可以同时存在多个。各类型分支之间的关系用一张图来体现就是：
不要直接在组织的原项目上进行开发。原因是为了避免原项目的主分支污染、做好分支管理、方便每次合并code review。请按照以下流程：
- fork组织项目到�自己仓库
- git pull 自己仓库的项目。
- 个人在「develop」分支开发项目。
- git remote add upstream http://**** // 本地添加远程主分支。
- git fetch upstream // 获取主分支的最新修改到本地。
- git merge upstream/develop // 将远程分支的「develop分支merge到本地。
- git push origin // 将本地修改提交到个人分支。
- 从自己仓库提pull request来合并本地「develop分支代码到远程仓库的「develop」。
- 如果有冲突，解决冲突。
- 如果没有冲突，管理员会进行code review，review通过后会合并到远程仓库的「develop」分支；review没有通过则修改后再次回到步骤7。
如果线上项目出现bug，需要紧急修复：
- 从当前线上项目的「release」分支派生出一个「hotfix」分支。
- 在「hotfix」上修改bug然后立即发布到线上。
- 不要忘记在「master」分支把这个bug修改或者meger已修改的「hotfix」进去。
对于项目管理员，初次之外要做的事情有：
- 每次用户提交后要做code review。
- 把稳定版本
- 对于某些版本需要打tag定版本号
如果这段简短的不足以解释清我们的工作流程，那需要看下git工作流指南。
原则上一个故事点一个commit，例如一个最小颗粒度的新功能，一个bug的修改，一个单独组件的UI修改，一个测试用例，一个性能优化所做的修改。
<type>(<scope>): <subject>
参考：git commit -m 'fix(用户管理): 修复模板编译错误'type 类型:
- feat：开发新功能（feature）
- fix：修补bug
- doc：写了文档（documentation）
- style： 格式（不影响代码运行的变动）
- refactor：重构（即不是新增功能，也不是修改bug的代码变动）
- performance：性能优化
- test：增加测试
- build：构建过程或辅助工具的变动
项目管理员需要做版本管理，版本记录在package的vsersion中，为三位小数模式如1.2.3，前后端项目的版本一致，意义如下：
- 最高位1：表示一个不向下兼容的大版本
- 次高位2：每一个迭代周期所发的版本，主要是做了需求的版本
- 最低位3：小版本，主要是改了bug的版本
可以直接提Issues反馈问题和建议，以及通过pull request的方式来贡献代码。