Appearance
vue技术栈前端建设方案
本节目标：理解“vue技术栈前端建设方案”的核心思路，并能把它用于实际开发或面试表达。
Brizer 码农 https://github.com/brizer前言 主要介绍云课堂前端在CRM系统的前端建设方面的经验总结，方便其他前端人做技术选型，全栈工程师快速建站。本文适合对vue技术栈和前端工具化、工程化感兴趣的朋友。 整体架构 CRM系统的服务端是基于node的，前端是以vue技术栈为主的。前端部分整体架构图如下：
**应用层**
整体前端应用层基于vue技术栈的传统三大件：路由层由[vue-router](https://link.zhihu.com/?target=https%3A//github.com/vuejs/vue-router)统一管理。基础组件库则是选择了基于vue的[elementui](https://link.zhihu.com/?target=https%3A//github.com/ElemeFE/element)。同类型的组件库还有[bootstrap-vue](https://link.zhihu.com/?target=https%3A//github.com/bootstrap-vue/bootstrap-vue)、[ant-design-vue](https://link.zhihu.com/?target=https%3A//github.com/vueComponent/ant-design-vue)等。数据store管理则采用了vue官方推荐的vuex来全局维护store。其他数据管理方案可以采用mobx配合mobx-vue来局部管理多个store。
至于util库则是选择了传统的[lodash](https://link.zhihu.com/?target=https%3A//github.com/lodash/lodash)。当然你也可以选择完全基于函数式编程范式的[ramda](https://link.zhihu.com/?target=https%3A//github.com/ramda/ramda)和基于ts构建的[remeda](https://link.zhihu.com/?target=https%3A//github.com/remeda/remeda)。
至于发送请求的库，我们选择了[axios](https://link.zhihu.com/?target=https%3A//github.com/axios/axios)，其方便的拦截处理和插件拓展功能非常实用。也有其他备选方案如[request](https://link.zhihu.com/?target=https%3A//github.com/request/request)和[superagent](https://link.zhihu.com/?target=https%3A//github.com/visionmedia/superagent)。
**工具层**
在应用层的选型维度之外，我们也进行了一些工具化的建设。
在mock数据方面，虽然配合axios的[axios-mock-adapter](https://link.zhihu.com/?target=https%3A//github.com/ctimmerm/axios-mock-adapter)很好用，但是其限制了使用范围（必须和axios配合），并且需要进行额外的逻辑侵入。结合网易自研的[nei](https://link.zhihu.com/?target=https%3A//github.com/x-orpheus/nei-toolkit)的编辑优势和webpack-dev-server的方便配置，团队自研了[http-mocker](https://link.zhihu.com/?target=https%3A//github.com/brizer/http-mocker)，提高mock的体验和效率。通过可视化界面编辑数据，并灵活切换远程本地代理，达到mock的效果。
在工程构建方面，选择了业界主流的[webpack](https://link.zhihu.com/?target=https%3A//github.com/webpack/webpack)作为打包工具。这里需要注意的是，为了优化加载文件大小，需要好好利用其[code splitting](https://link.zhihu.com/?target=https%3A//webpack.js.org/guides/code-splitting/%23root)功能。
在工程组件模板方面，团队自研了[yoso](https://link.zhihu.com/?target=https%3A//github.com/Linjovi/yoso)，动态切换github和gitlab模板库，方便程序员同时为社区和企业做贡献。
在一些其他的格式化管理方面，充分利用了git钩子，基于[husky](https://link.zhihu.com/?target=https%3A//github.com/typicode/husky)做了一系列优化，后面会具体谈到。
**测试**
针对应用的质量，我们进行了组件和util维度的单元测试、数据状态管理的单元测试和部分重要逻辑的UI自动化测试。
针对组件和util的单元测试，我们基于由Facebook出品的[jest](https://link.zhihu.com/?target=https%3A//github.com/facebook/jest)，传统的[mocha](https://link.zhihu.com/?target=https%3A//github.com/mochajs/mocha)和[chai](https://link.zhihu.com/?target=https%3A//github.com/chaijs/chai)还有覆盖率工具[istanbul](https://link.zhihu.com/?target=https%3A//github.com/gotwarlost/istanbul)需要自己去单独引用，配置较为繁琐。而jest则全套集成，方便快捷。
针对重要的基础组件，基于[jest-serializer-vue](https://link.zhihu.com/?target=https%3A//github.com/eddyerburgh/jest-serializer-vue)配合jest的快照测试功能，来确保模板的输出结果一致性。
针对Vuex的数据状态管理的测试，个人认为其重要性仅次于util，这里推荐一个自己参与开发的工具[vue-test-actions](https://link.zhihu.com/?target=https%3A//github.com/biigpongsatorn/vue-test-actions)，可以简化很多重复的逻辑。
针对UI自动化的测试，基于无头浏览器[puppeteer](https://link.zhihu.com/?target=https%3A//github.com/puppeteer/puppeteer)，以及jest对应的插件[jest-puppeteer](https://link.zhihu.com/?target=https%3A//github.com/smooth-code/jest-puppeteer)。这里也可以选择[cypress](https://link.zhihu.com/?target=https%3A//github.com/cypress-io/cypress)，虽然可视化的体验更好，但是也更加重型。而个人觉得既然单元测试选择了jest，通过jest-puppeteer来配合puppeteer也可以达到需求。
**可维护、美化**
我们在git钩子中通过[husky](https://link.zhihu.com/?target=https%3A//github.com/typicode/husky)配合[lint-staged](https://link.zhihu.com/?target=https%3A//github.com/okonet/lint-staged)可以做很多有意义的事情，这里列举几个实例。
**代码美化**
在commit阶段，通过[prettier](https://link.zhihu.com/?target=https%3A//github.com/prettier/prettier)，对代码进行指定格式的修改和美化，配置方式如下：
"lint-staged": { "src/*.js": [ "prettier --write", "git add" ] }, "husky": { "hooks": { "pre-commit": "lint-staged" } },
**校验commit信息**
校验commit信息是否符合规范，这里我们采用了[AngularJS Git Commit Message Conventions](https://link.zhihu.com/?target=https%3A//gist.github.com/stephenparish/9941e89d80e2bc58a153)，严格语义的提交信息，可以在工具化时做很多事情，比如说配合[conventional-changelog](https://link.zhihu.com/?target=https%3A//github.com/conventional-changelog/conventional-changelog)通过获取git元数据自动生成changelog等。
配置如下：
"husky": { "hooks": { "commit-msg": "node build/verifyCommitMsg.js" } }
verifyCommitMsg.js文件内容如下：
const color = require('chalk');const msgPath = process.env.HUSKY_GIT_PARAMSconst 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](https://link.zhihu.com/?target=https%3A//github.com/kevinoid/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](https://link.zhihu.com/?target=https%3A//github.com/getsentry/sentry)，并使用了其私有化部署工具[onpremise](https://link.zhihu.com/?target=https%3A//github.com/getsentry/onpremise)。
在多工程维护管理方面，个人认为组件或者模块适合用mono-repo的风格管理，使用[lerna](https://link.zhihu.com/?target=https%3A//github.com/lerna/lerna)这样的工具。而工程规模的才是采用multi-repo风格来管理比较合适。为了提高多个工程分支等操作时的便捷性，团队自研了[multi-repo-git](https://link.zhihu.com/?target=https%3A//github.com/brizer/multi-repo-git)，来提高分支操作的效率。从此再也不用同时开好几个控制台面板了。
**总结**
以上就是本次分享的全部经验了，如果各位对其中某些选择觉得不妥，或者对某些自研工具有同场景下更好的开源解决方案，欢迎交流。