「本文已参与好文召集令活动,点击查看:后端、大前端双赛道投稿,2万元奖池等你挑战!」
本文是一篇白话的技术教程文章,手把手教你搭建一个Vue3+Typescript的开发环境,其中可能涉及到比较多的基础知识,也有一些实践的经验和避雷针。如果你是一名老司机,可以选择跳跃浏览,但如果你是一个前端新人又或者你还没有完整的搭建过开发环境,我希望你能跟着文章亲手搭建一个。很多人在看到比如Vue-Router,Vuex,Eslint等词的时候就觉得索然无味,你真的清楚它们是怎么集成到项目中的吗?
实践出真知
基础架构
初始化项目
通过vite创建基础的项目架构,如果你还没有安装vite,快速安装如下:
- npm
npm install @vitejs/app
- yarn
yarn create @vitejs/app
使用vite初始化项目:
npm init @vitejs/app v3-ts-project
按照提示选择我们需要的模版,这边我们选择vue+ts的模版。
对项目初步净个身,删除HelloWorld组件以及相关引用的地方。
集成路由
npm install vue-router@4
安装成功后,在配置路由之前先对vite做一些配置:
配置别名
- resolve.alias
当使用文件系统路径的别名时,请始终使用绝对路径。相对路径的别名值会原封不动地被使用,因此无法被正常解析。
我们先要安装一个包@types/node
npm install @types/node --save-dev
编辑下vite.config.js
// vite.config.js
import { defineConfig } from 'vite'
import vue from '@vitejs/plugin-vue'
import { resolve } from 'path'
// https://vitejs.dev/config/
export default defineConfig({
plugins: [vue()],
base:'./', // 开发公共基础路径
resolve:{
alias:{
'@':resolve(__dirname,'src'), // 设置 @ 指向 /src 目录
// '@components':resolve(__dirname,'src/components'),
// '@pages':resolve(__dirname,'src/pages')
}
},
})
设置别名减少了代码中相对路径,不用担心层级问题,路径明确,有利于代码维护,也逐渐变成了一种代码规范。
设置<router-view>
// App.vue
<template>
<router-view></router-view>
</template>
<script lang="ts">
import { defineComponent } from 'vue'
export default defineComponent({
name: 'App',
})
</script>
...
配置路由入口
在src目录下创建router/index.ts文件。
// /src/router/index.ts
import {
createRouter,
createWebHashHistory,
RouteRecordRaw,
} from 'vue-router';
import Home from '@/views/home/index.vue';
import Detatil from '@/views/detail/index.vue';
const NotFound = () => import('@/views/notFound/notFound.vue') // 动态导入
const routes:Array<RouteRecordRaw> = [
{
path: '/',
name: 'Home',
component: Home,
},
{
path: '/detail',
name: 'detail',
component: Detatil,
},
{
path: '/:pathMatch(.*)*',// 404
name: 'notFound',
component: NotFound,
},
];
const router = createRouter({
history: createWebHashHistory(),
routes,
});
export default router;
如果将NotFound的引入改成
import NotFound from '@/views/notFound/notFound.vue';
系统加载路由的时候会一次性把静态导入的组件全部加载进来,如图:
动态导入的意思是,只有访问到了对应的路径才会对应的加载组件。考虑到为了减少资源占用,提高首页展示速度,非主要页面我们尽量采用动态导入的方式。
挂载
// main.ts
import { createApp } from 'vue'
import App from './App.vue'
import router from './router';
createApp(App)
.use(router)
.mount('#app')
我们的路由配置基础完成了。
更多详细的配置请参考vue-router官网。
集成vuex
首先安装vuex:
- npm
npm install vuex@next --save
- yarn
yarn add vuex@next --save
创建目录结构
在src目录下创建以下文件:
/src/store/index.ts/src/store/modules/user.ts
先编辑user.ts
// src/store/index.ts
// 为 store state 声明类型
export interface State {
name: string,
}
// 默认状态
const defaultState = {
name: ''
}
const user = {
namespaced: true,
state: () => defaultState,
mutations: {
setName(state:typeof defaultState, payload: string){
state.name = payload
}
},
actions: {
patchName (context: any) {
context.commit('setName','小明')
}
},
getters: {
getDemoName(state:typeof defaultState){
return state.name + 'demo';
}
}
}
export default user;
编辑index.ts
// /src/sotre/index.ts
import { InjectionKey } from 'vue'
import { createStore, Store } from 'vuex'
import user from './modules/user';
// 定义 injection key
export const key: InjectionKey<Store<any>> = Symbol('store的唯一标识');
export const store = createStore({
modules:{
user
}
})
挂载
// main.ts
import { createApp } from 'vue'
import App from './App.vue'
import router from './router';
import { store, key } from './store';
createApp(App)
.use(router)
.use(store, key)
.mount('#app')
vuex配置完成。
注意:在
Typescript中,我们在组件中使用useStore的时候需要把key传进去,否则获取不到store。
环境变量和模式
vite提供了一个特殊的全局对象import.meta.env,这个对象将暴露出来当前的环境变量,vite使用 dotenv 从你的 环境目录 中的加载环境变量文件。
.env # 所有情况下都会加载
.env.local # 所有情况下都会加载,但会被 git 忽略
.env.[mode] # 只在指定模式下加载
.env.[mode].local # 只在指定模式下加载,但会被 git 忽略
为了防止意外地将环境变量泄露,vite规定只有以 VITE_ 为前缀的变量才会暴露给import.meta.env对象。
OK,我们来操作一下:
首先在根目录下创建三个文件:
.env.local // 开发环境
.env.staging // 预发环境
.env.production // 生产环境
它们的内容大致如下:
.env.local:
# .env.local
NODE_ENV=development
VITE_API_BASE_URL="https://development.com"
.env.staging:
# .env.staging
NODE_ENV=staging
VITE_API_BASE_URL="https://staging.com"
.env.production:
# .env.production
NODE_ENV=production
VITE_API_BASE_URL="https://production.com"
默认情况下,vite 只有开发和生产环境,但是我们可以更具--mode来新增环境。
我们来编辑下package.json,修改下启动命令:
// package.json
...
"scripts": {
"dev": "vite --mode development",
"build": "vue-tsc --noEmit && vite build",
"prebuild": "vue-tsc --noEmit && vite build --mode staging",
"serve": "vite preview",
"prepare": "husky install"
},
这样当我们
- 运行
npm run dev的时候会默认读取.env.local的配置文件 - 运行
npm run prebuild的时候会默认读取.env.staging的配置文件 - 运行
npm run build的时候会默认读取.env.production的配置文件
文件中的变量都会被加入到import.meta.env对象上。
这样我们到时候可以根据不同的分支,通过CI执行不同的编译命令,从而发布不同环境下的版本啦(具体关于CI的请继续往后看)。
集成axios
通常情况下我们需要封装一下请求,对请求做统一的出入管理,比如设置请求的一些自定义的请求头参数,比如token等,同时还需要对请求结果的数据做格式转换,处理全局报错等。
安装axios
npm install axios -D
我们在src目录下新建untils/axios.ts文件:
// src/untils/axios.ts
import axios from 'axios';
// 环境变量
const API_BASE_URL: any = import.meta.env.VITE_API_BASE_URL;
const instance = axios.create({
baseURL: API_BASE_URL,
timeout: 20000,
});
// 添加请求拦截器
instance.interceptors.request.use(
(response) => {
// 设置token等...
response.headers = {};
return response;
},
/**
* 根据你的项目实际情况来对 config 做处理
* 这里对 config 不做任何处理,直接返回
*/
(error) => Promise.reject(error)
);
// 添加响应拦截
axios.interceptors.response.use(
(response) =>
/**
* 做一些可定制化的数据处理操作
*/
response,
(error) => {
const { code } = error.response.status;
/**
* 做一些全局的错误处理操作
*/
switch (code) {
case 401:
/** 权限处理 */
break;
case 500:
break;
default:
break;
}
return Promise.reject(error);
}
);
export default axios;
使用
引入axios:
import axios from '@/untils/axios.ts';
const test = () => {
axios.get('https://www.fastmock.site/mock/2f82fcaef2f445bf7e05e7ff91eb86b0/api/getProducts')
.then((res) => {
console.log(res);
}).catch((err) => {
console.log(err);
});
}
更过关于axios的请求方法的用法请参考官网:传送们
注意:给大家分享一个在线生成请求网址:fastmock,真的好用!
集成UI框架
目前支持vue3的UI框架主要有以下几种:
我们这边选择Element Plus,其他框架请自行参考文档。
安装:
npm install element-plus --save
在main.ts中挂载
// main.ts
import { createApp } from 'vue'
import ElementPlus from 'element-plus'
import 'element-plus/lib/theme-chalk/index.css';
import App from './App.vue'
import router from './router';
import { store, key } from './store';
createApp(App)
.use(router)
.use(store, key)
.use(ElementPlus)
.mount('#app')
集成css预处理器
less
npm install less -D
sass
npm install sass -D
代码规范
集成eslint
eslint是一种检查机制,有效的帮助我们统一规范。在多人开发的团队和项目中是必不可少的。随着使用者越来越多,已经有形成了基本完善的规则体系,不需要我们做过多配置操作,已经有成熟的规则方案给我们选择,站在巨人的肩膀上少走很多弯路。来看看:
安装eslint
npm install eslint --save-dev
紧接着设置一个配置文件:
注意:在项目的根目录的终端执行以下命令
./node_modules/.bin/eslint --init
随后会在终端出现一系列的问题,我们依次选择如下选项:
- To check syntax, find problems, and enforce code style(检查语法、发现问题并强制执行代码样式)
- JavaScript modules (import/export)
- Vue.js
- Yes
- Node
- Use a popular style guide
- Airbnb: github.com/airbnb/java… (社区最受欢迎的规则方案)
- JavaScript
完成后会提示安装一些依赖,选择安装。
安装完成后会在根目录出现.eslintrc.js文件:
// .eslintrc.js
module.exports = {
env: {
browser: true,
es2021: true,
node: true,
},
extends: [
'plugin:vue/essential',
'airbnb-base',
],
parserOptions: {
ecmaVersion: 12,
parser: '@typescript-eslint/parser',
sourceType: 'module',
},
plugins: [
'vue',
'@typescript-eslint',
],
rules: {
},
};
你可以在rules中配置一些定制化的团队规则,请参考eslint。
使用
接下来你可以运行命令对你的文件进行检查:
./node_modules/.bin/eslint 你的文件
比如:
./node_modules/.bin/eslint ./src/store/index.ts
我对之前的store/index.ts文件进行了检测,发现了很多的问题:
如果想要自动修复可以在后面添加--fix选项:
./node_modules/.bin/eslint ./src/store/index.ts --fix
有些问题通过eslint本身的自动修复也是没办法处理的,比如:
这个时候需要我们对eslint做一些配置:
// .eslintrc.js
module.exports = {
env: {
browser: true,
es2021: true,
node: true,
},
extends: ['plugin:vue/essential', 'airbnb-base', 'prettier'],
parserOptions: {
ecmaVersion: 12,
parser: '@typescript-eslint/parser',
sourceType: 'module',
},
plugins: ['vue', '@typescript-eslint', 'prettier'],
rules: {
'vue/no-multiple-template-root': 'off', // 解决template中最顶层只能返回一个元素的检测报错
'import/extensions': [
// 其他文件可不加扩展,引入vue文件需要加
'error',
'never',
{
vue: 'always', // 在ts中引入vue模块不加.vue后缀ts会找不到模块,这边验证vue文件的引用一定加.vue后缀
},
], // 解决导入文件后缀问题
'import/no-unresolved': [ // 解决无法识别问题
2,
{
ignore: ['./'],
},
],
"import/no-extraneous-dependencies": ["error", { "devDependencies": true }], // 解决依赖问题
"no-param-reassign": [ // 解决不能直接修改参数问题
"error",
{
"props": true,
"ignorePropertyModificationsFor": [
"request",
"res",
"response",
"state"
]
}
]
},
};
注意:在
ts中引入vue模块不加.vue后缀ts会找不到模块,所以要设置eslint校验文件后缀的配置。
安装插件
安装插件其实是为了提高我们的开发体验,让我们不必每次都跑命令去lint代码。不同的IDE还需要安装对应的插件,可以查看官网查询。
作者以vscode为例,在vscode的插件市场中安装eslint插件:
然后打开vscode的setting.json(command+shift+p)添加如下设置:
// setting.json
...
"editor.codeActionsOnSave": {
"source.fixAll.eslint": true
}
这样我们在保存代码的时候就会执行eslint
基本配置完毕。
集成prettier
安装prettier
官网:prettier.io/
npm install --save-dev --save-exact prettier
随后在项目根目录创建一个名为.prettierrc.json的配置文件,告诉IDE你正在使用prettier。
你还可以创建一个.prettierignore文件配置文件来忽略你不想prettier的目录,和.gitignore一样。
我们现在可以使用命令行对文件进行格式化,.表示所有文件:
npx prettier --write .
我们也可以配置setting.json设置保存后自动格式化:
// setting.json
"editor.formatOnSave": true,
格式化之后我们发现了一些改变:
prettier之前
<button @click="setName" @drag="setName" @mousedown="setName" @mouseover="setName">
修改名称
</button>
prettier之后
<button
@click="setName"
@drag="setName"
@mousedown="setName"
@mouseover="setName"
>
修改名称
</button>
除此之外,还有一些其他变化,比如单引号变成了双引号等,这就与我们之前Eslint产生了冲突。
可是我想同时保留两种格式化要怎么做呢?
解决冲突
首先我们要安装eslint-config-prettier用来关掉所有和Prettier冲突的Eslint的配置:
npm install eslint-config-prettier -D
然后在.eslintrc.js添加配置:
...
extends:[
...
"prettier" // 一定要放在最后,才能保证覆盖eslint
]
这表示格式化的优先级Prettier大于Eslint。
然后在对.prettierrc.json做一些基本配置,比如单引号的问题,我可以在Prettier中设置格式化的时候使用单引号:
{
"singleQuote": true
}
这样其实我们已经满足了上面说的两种情况,但是还会存在一个问题,我们希望不满足Prettier的规则也通过Eslint来提示。
我们通安装eslint-plugin-prettier将Prettier的rules以插件的形式加入到ESLint里面,最后都通过Eslint来报错。
npm install eslint-plugin-prettier -D
编辑 .eslintrc.js 文件:
plugins: ["vue", "@typescript-eslint", "prettier"],
rules: {
...
"prettier/prettier": "error",
},
这样我们开发环境的代码规范就配置好了。
集成stylelint
stylelint主要用来检查样式是否符合规范。
安装stylelint
npm install --save-dev stylelint stylelint-config-standard
stylelint-config-standard是stylelint推荐的一些默认样式规则。
然后在项目根目录下创建.stylelintrc.json配置文件并编辑,
// .stylelintrc.json
{
"extends": "stylelint-config-standard"
}
现在我们可以通过命令来格式化样式代码了
npx stylelint "**/*.vue"
为了提高效率,我们依旧需要在IDE使用插件来帮我们lint,依旧是以vscode为例,在插件市场搜索搜索stylelint,安装如下插件,
为了方便快捷,我们编辑一下setting.json文件:
// setting.json
...
"editor.codeActionsOnSave": {
"source.fixAll.eslint": true,
"source.fixAll.stylelint": true
},
集成husky
前提是项目使用的git进行代码提交。
husky的作用是保证提交的代码也是通过lint验证的。怎么理解呢,我们虽然在工程里面配置了代码规范,但实际在运作的时候,每个人的开发习惯不一样,用的IDE以也可能不一样,不能确保每个开发成员的IDE都安装了对应的插件或设置以保证我们的代码规范都被执行了。如果不在提交代码的时候进行验证,不符合规则的代码还是会被提交,这样我们的代码规范还是形同虚设。所以我们需要在提交的时候进行验证。
安装husky:
npx husky-init && npm install
安装完毕后,
-
首先会在我们的根目录下生成
.husky文件夹,这里面装的就是git hook的钩子函数执行文件,pre-commit钩子是在提交信息前执行的,即在我们git commit的时候触发。 -
同时会在
package.json的scripts中生成一条新的命令:"prepare": "husky install"。
我们再修改一下pre-commit的命令:
// pre-commit
#!/bin/sh
. "$(dirname "$0")/_/husky.sh"
../node_modules/.bin/eslint --fix
husky配置完毕,在我们提交代码的时候会执行eslint格式化代码。
但是这个格式化是针对项目的所有文件的,每次提交都要格式化所有代码,如果项目很大的话无疑会浪费很多时间和资源。我们希望最好只针对本次提交有改动的代码进行格式化,这就需要用到lint-staged工具了,我们来继续优化一下。
安装lint-staged
npm install lint-staged -D
你还可以使用
npx mrm@2 lint-staged
这个命令会同时帮你安装husky和lint-staged,并做好配置。
接下来我们修改package.json文件:
// package.json
...
"lint-staged": {
"*.{ts,vue,js}": "./node_modules/.bin/eslint --fix"
}
修改pre-commit:
#!/bin/sh
. "$(dirname "$0")/_/husky.sh"
npx lint-staged
到这里我们所有代码规范都配置好了。
为了验证一下,我将之前.eslintrc.js解决eslint无法自动修复的错误的配置去掉,然后提交代码:
注意:如果你本地没有进行
Eslint,如提交的时候Eslint通过了,还是会提交,但是你本地的不会有Eslint的结果,意思是,你本地的代码还是没有Eslint的代码,但是远程是Eslint的代码。
这个结果如我们预期的一样,我们再恢复.eslintrc.js的配置:
配置成功。
我们之前也对样式表做了格式化,所以虽然在IDE设置了保存时格式化代码,但是为了以防万一有的同学没有装IDE插件,我们还需要在提交的时候对样式进行lint检查,还需要修改下lint-staged添加一句配置:
// package.json
...
"lint-staged": {
"*.{js,vue,ts}": "./node_modules/.bin/eslint --fix",
"*.{html,vue,css,sass,scss}": "./node_modules/.bin/stylelint --fix"
}
提交规范
规范简介
我们通过git提交代码的时候需要填写message,否则无法提交。通常情况下我们提交的内容一定要突出重点,但是message没有规则,每个开发成员也可能都有自己的风格,比如:
- "新增了购物车的功能"
- "修改了新增不进去购物车的bug"
- "对购物车进行了重构"
时间久了,然后提交记录面板就会惨不忍睹,更看小说似的,如果有一天产品给你说我要上上上上个购物车版本的功能,这时候你可能会去提交记录里面找某一次历史提交改动的代码,这一找,人傻了,应该是听见产品说要上上上上个购物车版本的功能开始傻的。这只是一种场景,很多情况下我们会去查看提交记录面板,这个时候,我们需要一种规范来约束我们的提交格式,让我们能很明确的知道我这次提交内容是什么。目前社区里面最流行的是Conventional Commits,它受到Angular的提交准则的启发并以此为依据提供了一组创建清晰提交规则的简单规则,我们来看看:
提交记录主要分为三个部分:type、body、footer
<type>[optional scope]: <description>
[optional body]
[optional footer(s)]
type:必填,提交的类型,有以下类型:
| 类型 | 描述 |
|---|---|
| feat | 新增功能 |
| fix | 修复bug |
| docs | 修改文档 |
| refactor | 代码重构,未新增任何功能和修复任何bug |
| build | 改变构建流程,新增依赖库、工具等(例如webpack修改) |
| style | 仅仅修改了空格、缩进等,不改变代码逻辑 |
| perf | 改善性能和体现的修改 |
| chore | 修改构建流程或工具 |
| test | 测试用例的修改 |
| ci | 自动化流程配置修改 |
| revert | 回滚到上一个版本 |
body:必填,本次提交的主要描述,可多行。
footer:一些破坏性的重大改动或者不兼容的改动等必填,具体描述影响范围。否则可不填。
那具体我们应该怎么做呢?
我们可以利用Commitizen来帮我们快速的构建提交模版,但还是考虑到每个人的差异,有的人用git命令行,有的人习惯用git可视化工具,而工具又衍生更多的情况,统一是没办法统一的,他们也不可能被你统一的,所以这边就不用Commitizen了,解决这类问题还是那个方案,我们控制入场规则,自己去提交格式学习,在提交的时候我们通过commitlint去校验你的提交信息是否符合规范。很多时候,我们没有办法百分百去规范大家的行为,很多规范都是大家一同去维护,认可并执行的。
集成commitlint
首先安装commitlint:
npm install --save-dev @commitlint/{config-conventional,cli}
Windows环境:
npm install --save-dev @commitlint/config-conventional @commitlint/cli
在根目录下创建一个配置文件commitlint.config.js
// commitlint.config.js
module.exports = {extends: ['@commitlint/config-conventional']}
然后我们还需要借助husky的commit-msg钩子,执行命令:
npx husky add .husky/commit-msg 'npx --no-install commitlint --edit
这样我们就配置完成了,来测试一下。
不规范提交:
规范提交:
配置成功。
自动化
谈到前端自动化就不得不提到持续集成,持续交付,持续部署,是互联网敏捷开发的过程中一个非常重要的环节,通常用来进行日常编译,单元测试,构建,打包及自动部署。从我们提交代码到发布版本这个过程的行为通常是重复的,我们通过软件,程序使这个过程自动化,而持续集成,持续交付,持续部署就是这个过程中不同的阶段,通常我们把提交代码到自动化测试称为持续集成(CI),构建,发布测试版本,交付给质量团队称之为持续交付(CD),自动发布到线上环境称之为持续部署(CD)。
gitlab-ci
我们这边主要介绍gitlab-ci。
首先说一说它运行的大致机制:每当我们push/merge代码的时候gitlab会识别我们项目里面一个名叫.gitlab-ci.yml的配置文件,gitlab-ci提供了一个gitlab-runner软件来创建一个程序跑这些任务。
了解完机制我们再来了解下一些抽象概念:
先来看一张图:
【Pipeline】:管道(流水线),.gitlab-ci.yml的执行流程,通常有多个任务阶段,可以字面意思理解这个流水线。
【stage】:任务阶段,每个阶段至少有一个任务或多个任务,只有一个阶段完成才会执行下一个阶段。
【job】:任务,我们写在.gitlab-ci.yml配置文件里面的一个个要执行的任务,是CI系统中的可以控制并于运行的最小单元,比如:npm install。
由于很多公司的gitlab-runner都是后端同学来配置的,这背后涉及到的东西我就不多说了,了解一些相关概念以及运行机制就行了,前端感兴趣的同学可以自己去深入实践一下。
这一节,我们主要来说一说.gitlab-ci.yml的配置文件要怎么配置。
在.gitlab-ci.yml文件中你可以定义以下这些东西:
- 你要运行的脚本。
- 你想要包含的其他配置文件和模板。
- 依赖项和缓存。
- 要按顺序运行的命令和要并行运行的命令。
- 你要将应用程序部署的位置。
- 你是否要自动运行脚本还是手动触发它们中的任何一个。
它是按照特定的语法进行描述的,让我们来看一个官方的例子:
stages: #定义阶段
- build # build阶段
- test # test阶段
build-code-job: # 定义的任务名称(自定义)
stage: build # 在build阶段执行
script: #依次执行的脚本
- echo "Check the ruby version, then build some Ruby project files:"
- ruby -v
- rake
test-code-job1: # 定义的任务名称(自定义)
stage: test # 在test阶段执行
script: #依次执行的脚本
- echo "If the files are built successfully, test some files with one command:"
- rake test1
test-code-job2: # 定义的任务名称(自定义)
stage: test # 在test阶段执行
script: #依次执行的脚本
- echo "If the files are built successfully, test other files with a different command:"
- rake test2
首先我们定义了两个阶段build和test。build阶段先执行,然后会执行所有属于build阶段的任务,然后再执行test阶段的任务,注意:处于同一阶段的不同任务是可以并行的,例如以上例子中在test阶段会同时跑test-code-job1和test-code-job2两个任务,同时进行单元测试,大大提高了效率。
那我们再来看一个实际项目.gitlab-ci.yml配置文件:
# 缓存node_modules
cache:
key: cache
paths:
- node_modules/
# 定义 stages 阶段
stages:
- install
- build
- deploy
# install 阶段的任务
job_install:
stage: install
only: # 限定代码提交的分支
- /^master$|^pre$|^dev$|^release-\d{0,}.\d{0,}.\d{0,}$/ # 使用正则匹配
script: #执行命令
- yarn install
- ...
# master build 阶段的任务
job_build:
stage: build
only:
- master
script:
- yarn build
artifacts: # 产出
paths:
- dist
expire_in: 120 mins # 有效时间
# dev build 阶段的任务
job_devbuild:
stage: build
only:
- dev
script:
- yarn devbuild
artifacts:
paths:
- dist
expire_in: 120 mins
# release build 阶段的任务
job_opsbuild:
stage: build
only:
- /^release-\d{0,}.\d{0,}.\d{0,}$/
script:
- yarn opsbuild
artifacts:
paths:
- dist
expire_in: 120 mins
# deploy 阶段的任务
job_deploy:
stage: deploy
only:
- /^master$|^pre$|^dev$|^release-\d{0,}.\d{0,}.\d{0,}$/
script:
- ...
首先缓存了node_modules下的包,定义了install、build、deploy三个阶段,通过only对分支进行判断,执行不同的构建命令,以达到不同环境下的持续交付。
更多具体的配置细节请参考官网:传送门。
总结
我们的vue3开发工程基本搭建完毕,集成了路由管理、管理、UI框架、代码规范、提交规范以及自动化构建,这套工程基本能满足我们的日常开发。
在写这篇文章的过程中,为了尽可能的简洁易懂的表达出来,作者也查阅了很多的资料和官网,有一种温故而知新的感觉,在分享知识的同时自己也在汲取知识,希望大家一起进步。
我会将这个工程放在github上。
如果有什么问题欢迎大家留言指正,谢谢。