vue技术栈前端建设方案
前言
主要介绍云课堂前端在CRM系统的前端建设方面的经验总结，方便其他前端人做技术选型，全栈工程师快速建站。本文适合对vue技术栈和前端工具化、工程化感兴趣的朋友。
整体架构
CRM系统的服务端是基于node的，前端是以vue技术栈为主的。前端部分整体架构图如下：
应用层
整体前端应用层基于vue技术栈的传统三大件：
- 路由层由 vue-router统一管理。
- 基础组件库则是选择了基于vue的 elementui。同类型的组件库还有 bootstrap-vue、 ant-design-vue等。
- 数据store管理则采用了vue官方推荐的 vuex来全局维护store。其他数据管理方案可以采用 mobx配合 mobx-vue来局部管理多个store。
至于util库则是选择了传统的 lodash。当然你也可以选择完全基于函数式编程范式的 ramda和基于ts构建的 remeda。
至于发送请求的库，我们选择了 axios，其方便的拦截处理和插件拓展功能非常实用。也有其他备选方案如 request和 superagent。
工具层
在应用层的选型维度之外，我们也进行了一些工具化的建设。
在mock数据方面，虽然配合axios的 axios-mock-adapter很好用，但是其限制了使用范围（必须和axios配合），并且需要进行额外的逻辑侵入。结合网易自研的 nei的编辑优势和webpack-dev-server的方便配置，团队自研了 http-mocker，提高mock的体验和效率。通过可视化界面编辑数据，并灵活切换远程本地代理，达到mock的效果。
在工程构建方面，选择了业界主流的 webpack作为打包工具。这里需要注意的是，为了优化加载文件大小，需要好好利用其 code splitting功能。
在工程组件模板方面，团队自研了 yoso，动态切换github和gitlab模板库，方便程序员同时为社区和企业做贡献。
在一些其他的格式化管理方面，充分利用了git钩子，基于 husky做了一系列优化，后面会具体谈到。
测试
针对应用的质量，我们进行了组件和util维度的单元测试、数据状态管理的单元测试和部分重要逻辑的UI自动化测试。
针对组件和util的单元测试，我们基于由Facebook出品的 jest，传统的 mocha和 chai还有覆盖率工具 istanbul需要自己去单独引用，配置较为繁琐。而jest则全套集成，方便快捷。
针对重要的基础组件，基于 jest-serializer-vue配合jest的快照测试功能，来确保模板的输出结果一致性。
针对Vuex的数据状态管理的测试，个人认为其重要性仅次于util，这里推荐一个自己参与开发的工具 vue-test-actions，可以简化很多重复的逻辑。
针对UI自动化的测试，基于无头浏览器 puppeteer，以及jest对应的插件 jest-puppeteer。这里也可以选择 cypress，虽然可视化的体验更好，但是也更加重型。而个人觉得既然单元测试选择了jest，通过jest-puppeteer来配合puppeteer也可以达到需求。
可维护、美化
我们在git钩子中通过 husky配合 lint-staged可以做很多有意义的事情，这里列举几个实例。
代码美化
在commit阶段，通过 prettier，对代码进行指定格式的修改和美化，配置方式如下：
"lint-staged": {
"src/*.js": [
"prettier --write",
"git add"
]
},
"husky": {
"hooks": {
"pre-commit": "lint-staged"
}
},校验commit信息
校验commit信息是否符合规范，这里我们采用了 AngularJS Git Commit Message Conventions，严格语义的提交信息，可以在工具化时做很多事情，比如说配合 conventional-changelog通过获取git元数据自动生成changelog等。
配置如下：
"husky": {
"hooks": {
"commit-msg": "node build/verifyCommitMsg.js"
}
}verifyCommitMsg.js文件内容如下：
const color = require('chalk');
const msgPath = process.env.HUSKY_GIT_PARAMS
const msg = require('fs').readFileSync(msgPath, 'utf-8').trim()
const commitRE = /^(v\d+\.\d+\.\d+(-(alpha|beta|rc.\d+))?$)|((revert: )?(feat|fix|docs|style|refactor|perf|test|workflow|ci|chore|types|build)(\(.+\))?: .{1,50})/
if (!commitRE.test(msg)) {
console.log()
console.error(
` ${color.bgRed(' ERROR ')} ${color.red(`invalid commit message format.`)}\n\n` +
color.red(` Proper commit message format is required for automated changelog generation. Examples:\n\n`) +
` ${color.green(`feat(compiler): add 'comments' option`)}\n` +
` ${color.green(`fix(v-model): handle events on blur (close #28)`)}\n\n` +
color.red(` See build/COMMIT_CONVENTION.md for more details.\n`) +
color.red(` You can also use ${color.cyan(`npm run commit`)} to interactively generate a commit message.\n`)
)
process.exit(1)
}
自动化部署
一般自动化部署是在其他CD机器上去做的，如果没有这个条件，甚至可以在git钩子阶段完成。但是需要注意的一点是，git钩子是没有push阶段的，所以需要通过延时，并且需要一些工具如 git-branch-is，来判断当前push的分支。
这里配置如下：
"husky": {
"hooks": {
"pre-push": "if git-branch-is -q test; then node build/deploy.js; fi"
}
}由于这里的部署脚本调用了网易内部NDP平台的API和秘钥，就不具体展示了。
工程化
前面提到了web应用、工具、测试、美化校验等相关点，这里说明下在工程化角度做的一些事情和经验。
首先，在CI方面，由于我们在commit阶段只是做了简单了代码美化，所以eslint和测试的执行过程都交给了Gitlab的runner。
在异常监控方面，我们选择了 sentry，并使用了其私有化部署工具 onpremise。
在多工程维护管理方面，个人认为组件或者模块适合用mono-repo的风格管理，使用 lerna这样的工具。而工程规模的才是采用multi-repo风格来管理比较合适。为了提高多个工程分支等操作时的便捷性，团队自研了 multi-repo-git，来提高分支操作的效率。从此再也不用同时开好几个控制台面板了。
总结
以上就是本次分享的全部经验了，如果各位对其中某些选择觉得不妥，或者对某些自研工具有同场景下更好的开源解决方案，欢迎交流。
原文链接，讨论地址