Nuxt3项目安装配置
安装 nuxt3
shell
npx nuxi init PROJECT_NAME
进入项目目录,并安装相关依赖
shell
cd PROJECT_NAME && yarn
安装完依赖之后,使用 yarn dev
启动项目,看到如下页面说明项目已经安装成功了。
集成 Eslint
通过以下命令安装 eslint
相关依赖
base
yarn add eslint @nuxtjs/eslint-module typescript @nuxtjs/eslint-config-typescript eslint-plugin-nuxt -D
之后进入 nuxt.config.ts
修改配置如下:
ts
import { defineNuxtConfig } from 'nuxt3'
// https://v3.nuxtjs.org/docs/directory-structure/nuxt.config
export default defineNuxtConfig({
modules: ['@nuxtjs/eslint-module']
})
创建 .eslintrc
文件,并添加以下内容:
json
{
"root": true,
"env": {
"browser": true,
"node": true
},
"extends": [
"@nuxtjs/eslint-config-typescript",
"plugin:nuxt/recommended"
],
"plugins": [],
"rules": {}
}
进入 package.json
配置 lint
运行脚本:
json
{
"script": {
// ...
"lint": "eslint --ext \".ts,.js,.vue\" --ignore-path .gitignore ."
}
}
配置 husky
如果之前没有初始化 git
仓库,需要先运行一下 git init
shell
npx husky-init && yarn
上面的命令做了四件事:
- 安装
husky
依赖; - 在项目根目录下创建
.husky
目录; - 在
.husky
目录创建pre-commit
钩子,并初始化pre-commit
命令为npm test
; - 在
package.json
的scripts
里面增加"prepare": "husky install"
脚本。
husky
包含很多钩子(hook),常用的有:pre-commit
、commit-msg
、pre-push
。
我们使用 pre-commit
来触发 eslint 命令。
修改 .husky/pre-commit
文件如下:
shell
#!/bin/sh
. "$(dirname "$0")/_/husky.sh"
eslint --fix --ext .ts,.js,.vue --ignore-path .gitignore
上面这个钩子文件的作用是:当我们执行 git commit -m 'xx'
命令时,会对项目中除了 .gitignore
中所有.ts
、.js
、vue
文件执行一次 eslint --fix
命令,如何 eslint 通过,则成功 commit
,否则终止 commit
。
那么问题来了,当我们只改动部分文件时,这个钩子却对所有的相关文件都执行一次 eslint --fix
,对其他未被修改的文件进行检查修复,有可能会造成很大的影响。
所以我们需要借助 lint-staged
这个工具来实现只对当前有改动的文件进行检查修复,不影响其他文件。
配置 lint-staged
lint-staged 一般结合 husky 来使用,它可以让 husky 的钩子只对 git add
加入暂存区的文件生效。
-
安装 lint-staged
shellyarn add lint-staged -D
-
在
package.json
里面增加相关配置json"lint-staged": { "*.{vue,js,ts}": "eslint --fix" }
-
修改
.husky/pre-commit
的触发命令为:npx lint-staged
shell#!/bin/sh . "$(dirname "$0")/_/husky.sh" npx lint-staged
至此,husky 和 lint-staged 组合配置完成。
集成 commitizen 实现规范的代码提交
commitized
是一个帮助撰写规范的 commit message
的工具。
安装
shell
yarn add commitizen -D
初始化
使用 cz-conventional-changelog
适配器来初始化项目
shell
yarn add cz-conventional-changelog -D
安装完后,在package.json
中增加下面代码:
json
"config": {
"commitizen": {
"path": "./node_modules/cz-conventional-changelog"
}
}
使用
之前我们提交代码都是使用 git commit -m 'xxx'
命令,现在改为 git cz
,然后按照终端的提示,一步一步地填写相关信息,最终生成规范的 commit message。
自定义配置提交说明
在默认的情况下,git cz
的终端提示都是英文的,如果想改成中文或者自定义这些选项的说明,我们可以使用 cz-customizable
适配器。
shell
yarn add cz-customizable -D
之后修改 package.json
中的 config.commitizen
字段
json
"config": {
"commitizen": {
"path": "./node_modules/cz-customizable"
}
}
在项目根目录下创建 .cz-config.js
文件,实现自定义配置。
js
module.exports = {
// type 类型(定义之后,可通过上下键选择)
types: [
{ value: 'feat', name: 'feat: 新增功能' },
{ value: 'fix', name: 'fix: 修复 bug' },
{ value: 'docs', name: 'docs: 文档变更' },
{ 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 类型(定义之后,可通过上下键选择)
scopes: [
['components', '组件相关'],
['hooks', 'hook 相关'],
['utils', 'utils 相关'],
['styles', '样式相关'],
['deps', '项目依赖'],
['auth', '对 auth 修改'],
['other', '其他修改'],
// 如果选择 custom,后面会让你再输入一个自定义的 scope。也可以不设置此项,把后面的 allowCustomScopes 设置为 true
['custom', '以上都不是?我要自定义']
].map(([value, description]) => {
return {
value,
name: `${value.padEnd(30)} (${description})`
}
}),
// 是否允许自定义填写 scope,在 scope 选择的时候,会有 empty 和 custom 可以选择。
// allowCustomScopes: true,
// allowTicketNumber: false,
// isTicketNumberRequired: false,
// ticketNumberPrefix: 'TICKET-',
// ticketNumberRegExp: '\\d{1,5}',
// 针对每一个 type 去定义对应的 scopes,例如 fix
/*
scopeOverrides: {
fix: [
{ name: 'merge' },
{ name: 'style' },
{ name: 'e2eTest' },
{ name: 'unitTest' }
]
},
*/
// 交互提示信息
messages: {
type: '确保本次提交遵循 Angular 规范!\n选择你要提交的类型:',
scope: '\n选择一个 scope(可选):',
// 选择 scope: custom 时会出下面的提示
customScope: '请输入自定义的 scope:',
subject: '填写简短精炼的变更描述:\n',
body:
'填写更加详细的变更描述(可选)。使用 "|" 换行:\n',
breaking: '列举非兼容性重大的变更(可选):\n',
footer: '列举出所有变更的 ISSUES CLOSED(可选)。 例如: #31, #34:\n',
confirmCommit: '确认提交?'
},
// 设置只有 type 选择了 feat 或 fix,才询问 breaking message
allowBreakingChanges: ['feat', 'fix'],
// 跳过要询问的步骤
// skipQuestions: ['body', 'footer'],
// subject 限制长度
subjectLimit: 100,
breaklineChar: '|', // 支持 body 和 footer
// footerPrefix : 'ISSUES CLOSED:'
// askForBreakingChangeFirst : true,
}
我们可以通过上面的配置来完成自定义配置规则,建议大家结合项目实际情况来配置,更多的配置规则可以参考官方配置示例。
集成 commitlint 验证提交规范
尽管我们制定了提交规范,但在多人协作的项目中,依旧有人我行我素,因此我们还需要增加一个限制,只让符合提交规范的提交信息通过,我们借助 @commitlint/config-conventional
和 @commitlint/cli
来实现。
安装
shell
yarn add @commitlint/config-conventional @commitlint/cli -D
配置
在根目录下创建 commitlint.config.js
文件,并写入以下内容:
js
module.exports = { extends: ['@commitlint/config-conventional'] }
使用 husky 的 commit-msg
钩子触发验证提交信息的命令。
shell
npx husky add .husky/commit-msg "npx --no-install commitlint --edit $1"
使用上面的命令在 .husky
目录下创建 commit-msg
文件,并在此写入验证命令。
至此我们的项目已经完成初始化配置,集成了eslint
、lint-staged
、commitizen
和commitlint
。我们可以在终端输入git cz
根据终端提示完成我们的第一个 commit。