【前端工程化】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即可
1
2
3
4
5
6
7
8
9
10
11
// 在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赏，则可以在这里对不同情况进行处理。
1
2
3
4
5
6
7
8
9
10
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
配置在提交代码前进行代码检测是非常重要的！
1
2
# 安装husky和lint-staged
yarn add -D husky lint-staged
1
2
# 安装commitlint
yarn add -D @commitlint/cli @commitlint/config-conventional commitizen conventional-changelog-cli cz-customizable
配置检测，在根目录下的.husky下需要配置命令，可以参考demo
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
// 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格式的检测
1
2
3
4
5
6
7
8
9
// pacakge.json
"config": {
"commitizen": {
"path": "./node_modules/cz-customizable"
},
"cz-customizable": {
"config": ".cz-config.js"
}
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
// .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
1
2
3
4
5
6
7
8
9
10
11
12
// 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的配置如下
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
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即可
1
2
3
4
5
6
7
8
9
10
11
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的礼物！