【前端工程化】Vite关于Vue3/React项目工程化总结（献给2021-1024的礼物）

时间已经是2021年了，马上也就2022年了，现如今自己的关注点对于新知识的狂热程度也比当年稍减，更多的关注于该新玩意对于现有项目是否有提升的可能性。更多地关注于项目的工程化和稳定性。关于Vite的项目工程化实践也有快一年了，从Vue3刚发布的踩坑实践到现在几乎可以覆盖99.5的机型兼容.是时候在1024节，给大家献上一篇总结啦～

当然也可以查看我之前在公司内部分享的ppt：vadxq的分享ppt小栈

技术栈

Vue3 工程化项目实践demo

• 编程语言：TypeScript 4.x
• 构建工具：Vite 2.x
• 前端框架：Vue 3.x
• 路由工具：Vue Router 4.x
• 状态管理：Vuex 4.x
• CSS：Sass + Postcss
• HTTP 工具：Axios
• MOCK: mockjs + vite plugins
• 移动端调试插件: vite-plugin-vconsole
• Git Hook 工具：Husky + Lint-staged
• 代码规范：EditorConfig + Prettier + ESLint
• 提交规范：Commitlint + changelog

项目细节介绍

• .husky: 关于Git Hook工具的一些命令配置
• .vscode: 关于vscode的一些配置，强制开启一些检测插件
• build: 关于持续集成，构建和部署相关的node脚本
• mocks: mock数据
• public: 静态文件夹
• src: 主要代码相关
• .cz-config.js: 关于commit规范的配置
• .env: 环境变量配置
• .eslintrc/.eslintignore: eslint配置
• .gitignore: 懂得都懂
• .prettierignore/.prettierrc: 格式配置
• .stylelintrc.json: 样式格式化配置
• commitlint.config.js: commitlint配置
• index.html: index.html文件
• package.json
• postcss.config.js: postcss配置
• tsconfig.json
• vite.config.ts: vite配置

先谈谈Vue和React项目内部的实践

Vue3

跑Vue3，其实很简单，在src目录配置main.ts和App.vue入口文件即可。可以参考Vue3官方文档，本文不做过多描述。

而在Vite的配置也很简单，只需要引入@vitejs/plugin-vue即可。配置就一句Vue()。是不是很方便？当然，今天讲的更多是工程化方面，这里简单提一句，可以参考demo项目vite-vue-prod-template。

React

跑React，也很简单，在src目录配置main.ts和App.tsx入口文件即可。而在Vite的配置也很简单，只需要引入@vitejs/plugin-react-refresh即可。配置就一句reactRefresh()。非常的方便。可以参考demo项目vite-react-starter。

谈谈两者的工程化

关于结构约定

在前端，其实是很自由化的，模块化的，无处不在。但是对于公司项目来说，这种自由化，会导致项目在人才更替的时候，出现难以维护的情况，所以每一个项目，都需要相互约定一个特定的共同认可的项目结构。通用的几乎不需要修改的配置等提取出来，放入初始化项目里。根据业务类型区分不同的文件夹，约定特定的业务在特定的文件结构里进行编码。比如apis，编写与服务端交互的调用api接口代码。routes则为前端路由相关，styles为公共样式文件，views为页面代码，components为组件等等，这些约定每个团队可能都不一样，这里可以大家自己参考demo项目，与团队成员约定结构，这一步也是很重要的哟～

关于环境与构建相关

其实前端的部署很简单，将代码build出来即可。对于公司的项目来说，不可能只有两个环境：development和production。往往至少会有测试环境，甚至有多个测试环境和预生产环境。不同环境的打包也是不一样的，打包通过Vite的配置即可处理大部分情况，当然生产环境可能需要上传静态文件到OSS搭配CDN。这里需要根据自己公司的业务去做针对性处理。demo项目是做了在build下对项目上传到七牛CDN下的处理方式。实现细节可以参考build/build.ts

关于环境的处理

环境的处理其实只要设定mode即可

// 在package.json
"scripts": {
  "dev": "vite --mode mock",
  "dev:alpha": "vite --mode alpha",
  "dev:test": "vite --mode test",
  "dev:test1": "vite --mode test1",
  "dev:grey": "vite --mode grey",
  "build:test": "vue-tsc --noEmit && vite build --mode test",
  "build:test1": "vue-tsc --noEmit && vite build --mode test1",
  "build": "vue-tsc --noEmit && vite build --mode prod"
},

关于Vite base的处理

这个是配置base，也就是index.html引入的.js/.css/静态文件等的前缀处理。比如index.html打包后引入app.bc8837848788.js，如果正式环境配置的是cdn情况下，或者是将静态文件放置在不同url赏，则可以在这里对不同情况进行处理。

base:
  mode === 'prod'
    ? `${cdnConfig.host}${projectBasePath}`
    : mode === 'test'
    ? baseConfig.publicPath + '/'
    : mode === 'test1'
    ? baseConfig.publicPath + '/'
    : mode === 'grey'
    ? baseConfig.publicPath + '/'
    : './',

关于部署与持续集成

这一块根据自家团队的情况自己处理啦。其实也就是几条命令，clone代码，安装node_modules，然后就是build，有上传oss/CDN的可以加一行上传命令，建议写在build下，最后就是将代码copy到服务器或者是serverless。

关于团队规范和git flow

团队规范是我很在意的一点。这一块针对性的做了很多的处理，包括常规js/ts代码规范的检测，还有css代码，以及文件格式的检测和commit规范的检测

关于Husky/lint-staged和commitlint

配置在提交代码前进行代码检测是非常重要的！

# 安装husky和lint-staged
yarn add -D husky lint-staged

# 安装commitlint
yarn add -D @commitlint/cli @commitlint/config-conventional commitizen conventional-changelog-cli cz-customizable

配置检测，在根目录下的.husky下需要配置命令，可以参考demo

// pacakge.json
"scripts": {
  "prepare": "husky install",
  "lint": "npx lint-staged"
},
"husky": {
  "hooks": {
    "commit-msg": "commitlint -E HUSKY_GIT_PARAMS",
    "pre-commit": "lint-staged"
  }
},
"lint-staged": {
  "*.md": "prettier . -w",
  "*.{ts,tsx,js,vue}": "eslint . --fix",
  "*.{vue,css,scss,less,sass}": "stylelint --fix",
  "*": "prettier . -w -u"
},

关于配置提交commit格式的检测

// pacakge.json
"config": {
  "commitizen": {
    "path": "./node_modules/cz-customizable"
  },
  "cz-customizable": {
    "config": ".cz-config.js"
  }
}

// .cz-config.js
// 配置可以参考demo的配置，有注释
module.exports = {
  // type 类型
  types: [
    { value: 'feat', name: 'feat:     新增产品功能' },
    { value: 'fix', name: 'fix:      修复 bug' },
    { value: 'upd', name: 'upd:      update,更新某功能（不是 feat, 不是 fix' },
    { value: 'docs', name: 'docs:     文档的变更' },
    { value: 'release', name: 'release:     版本，打tag' },
    {
      value: 'style',
      name: 'style:    不改变代码功能的变动(如删除空格、格式化、去掉末尾分号等)'
    },
    {
      value: 'refactor',
      name: 'refactor: 重构代码。不包括 bug 修复、功能新增'
    },
    {
      value: 'perf',
      name: 'perf:     性能优化'
    },
    { value: 'test', name: 'test:     添加、修改测试用例' },
    {
      value: 'build',
      name: 'build:    构建流程、外部依赖变更，比如升级 npm 包、修改 webpack 配置'
    },
    { value: 'ci', name: 'ci:       修改了 CI 配置、脚本' },
    {
      value: 'chore',
      name: 'chore:    对构建过程或辅助工具和库的更改,不影响源文件、测试用例的其他操作'
    },
    { value: 'revert', name: 'revert:   回滚 commit' }
  ],

  // scope 类型，针对 React 项目
  scopes: [
    // 如果选择 custom ,后面会让你再输入一个自定义的 scope , 也可以不设置此项， 把后面的 allowCustomScopes 设置为 true
    ['custom', '以下都不是？我要自定义,或者回车跳过此项'],
    ['components', '组件相关'],
    ['views', '页面相关'],
    ['utils', '工具函数相关'],
    ['apis', '接口对接相关'],
    ['layout', '调整layout和页面布局相关'],
    ['styles', '样式相关'],
    ['deps', '项目依赖'],
    ['other', '其他修改']
  ].map(([value, description]) => {
    return {
      value,
      name: `${value.padEnd(30)} (${description})`
    };
  }),

  // allowTicketNumber: false,
  // isTicketNumberRequired: false,
  // ticketNumberPrefix: 'TICKET-',
  // ticketNumberRegExp: '\\d{1,5}',

  // 可以设置 scope 的类型跟 type 的类型匹配项，例如: 'fix'
  /*
    scopeOverrides: {
      fix: [
        { name: 'merge' },
        { name: 'style' },
        { name: 'e2eTest' },
        { name: 'unitTest' }
      ]
    },
   */
  // 覆写提示的信息
  messages: {
    type: '请确保你的提交遵循了原子提交规范！\n选择你要提交的类型:',
    scope: '\n选择一个 scope (可选):',
    // 选择 scope: custom 时会出下面的提示
    customScope: '请输入自定义的 scope:',
    subject: '填写一个简短精炼的描述语句:\n',
    body: '添加一个更加详细的描述，可以附上新增功能的描述或 bug 链接、截图链接 (可选)。使用 "|" 换行:\n',
    breaking: '列举非兼容性重大的变更 (可选):\n',
    footer: '列举出所有变更的 ISSUES CLOSED  (可选)。 例如.: #31, #34:\n',
    confirmCommit: '确认提交?'
  },

  // 是否允许自定义填写 scope ，设置为 true ，会自动添加两个 scope 类型 [{ name: 'empty', value: false },{ name: 'custom', value: 'custom' }]
  // allowCustomScopes: true,
  allowBreakingChanges: ['feat', 'fix'],
  // skip any questions you want
  // skipQuestions: [],

  // subject 限制长度
  subjectLimit: 100
  // breaklineChar: '|', // 支持 body 和 footer
  // footerPrefix : 'ISSUES CLOSED:'
  // askForBreakingChangeFirst : true,
};

关于移动端调试Vconsole

yarn add -D vconsole vite-plugin-vconsole

// vite配置,可以参考项目vite-plugin-vconsole的文档填写，兼容多环境情况
viteVConsole({
  entry: resolve(__dirname, './src/main.ts'),
  localEnabled: true,
  enabled:
    command !== 'serve' &&
    (mode === 'test' || mode === 'test1' || mode === 'alpha'),
  config: {
    maxLogNumber: 1000,
    theme: 'light'
  }
}),

关于兼容性的处理

最难处理的其实就是proxy。

引入@vitejs/plugin-legacy即可，vite的配置如下

legacy({
  // 不考虑ie的兼容性和老的vivo/锤子/荣耀等国产机型，则可以使用下面
  // targets: ['defaults', 'not IE 11', '> 0.25%, not dead'],
  // 如果考虑上面说的兼容性问题，使用下面配置
  targets: ['ie >= 11'],
  additionalLegacyPolyfills: ['regenerator-runtime/runtime'],
  // 下面可以根据情况选用
  renderLegacyChunks: true,
  polyfills: [
    'es.symbol',
    'es.array.filter',
    'es.promise',
    'es.promise.finally',
    'es/map',
    'es/set',
    'es.array.for-each',
    'es.object.define-properties',
    'es.object.define-property',
    'es.object.get-own-property-descriptor',
    'es.object.get-own-property-descriptors',
    'es.object.keys',
    'es.object.to-string',
    'web.dom-collections.for-each',
    'esnext.global-this',
    'esnext.string.match-all'
  ],
  modernPolyfills: ['es.promise.finally']
})

关于mock的处理

引入vite-plugin-mock即可

viteMockServe({
  mockPath: 'mocks',
  supportTs: true,
  localEnabled: command === 'serve' && mode === 'mock',
  prodEnabled: false
  //  这样可以控制关闭mock的时候不让mock打包到最终代码内
  // injectCode: `
  //   import { setupProdMockServer } from './mockProdServer';
  //   setupProdMockServer();
  // `
}),

关于日志收集

目前有阿里云的arms和自己搭建的sentry。

arms可以使用这个插件，根据不同环境去添加不同的arms。vite-plugin-arms.

sentry直接使用sentry提供的插件即可。

总结

好了，这次的总结就到此结束了。Vite在正式项目上，几乎毫无压力，工程化的沉淀也差不多就这样啦，具体的业务表现就自由发挥啦。

今天是2021年的1024～在此祝所有程序员节日快乐～我们的狂欢🎉！献给2020-1024的礼物！