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，来提高分支操作的效率。从此再也不用同时开好几个控制台面板了。

---

总结

以上就是本次分享的全部经验了，如果各位对其中某些选择觉得不妥，或者对某些自研工具有同场景下更好的开源解决方案，欢迎交流。

原文链接，讨论地址