前端工程化,搭建项目(eslint + preitter + husky + lint-staged + commitlint + com...)
基本介绍
本文主要描述手动搭建 vite 项目,并且通过 eslint、preitter、husky、lint-staged、commitlint、commitizen 来进行项目约束规范。
创建项目
首先创建项目文件夹,并初始化 package.json
# 初始化项目,添加 package.json
npm init
# 手动安装 vite
npm i vite -D
并在根目录创建一个像这样的 index.html 文件:
<!doctype html>
<html lang="en">
<head>
<meta charset="UTF-8" />
<meta name="viewport" content="width=device-width, initial-scale=1.0" />
<title>DEMO</title>
</head>
<body>
<p>Demo</p>
<script src="./index.ts" type="module"></script>
</body>
</html>
可以看到 script 中引入了 index.ts,终端中运行 vite,就可以访问到 index.html 页面。
后续配置的规范和这个html页面没啥关系,只是习惯就整个创建了
eslint
是什么
ESLint 是一个可配置的 JavaScript linter。它可以帮助你发现并修复 JavaScript 代码中的问题。问题可以是任何事情,从潜在的运行时错误到不遵循最佳实践,再到样式问题。
ESLint 是完全插件化的。每条规则都是一个插件,你可以在运行时添加更多。你还可以添加社区插件、配置和解析器来扩展 ESLint 的功能。
配置
# 下载 eslint 9
npm i eslint -D
# 初始化
npx eslint --init
# 或者直接执行
npm init @eslint/config@latest
执行完 npx eslint --init 后,又有相关的初始化配置选项。例如:

这里每个选项的意思都比较清晰,按需选择即可。
程序执行完后可以发现在根目录下生成 eslint.config.mjs 文件,里面包括内容
// eslint.config.mjs
import globals from 'globals'
import pluginJs from '@eslint/js'
import tseslint from 'typescript-eslint'
export default [
{ files: ['**/*.{js,mjs,cjs,ts}'] },
{ languageOptions: { globals: globals.browser } },
pluginJs.configs.recommended,
...tseslint.configs.recommended
// 新增添加内容:这里我们可以添加自己的 rules
{
rules: {
semi: ['error', 'never'], // 语句后不带分号
'no-unused-vars': 'error', // 没有使用的参数
'no-undef': 'error' // 没有定义参数
}
},
{
ignores: ['node_modules/'] // 忽略目录
}
]
rules 相关要更改规则的严重性,请将规则 ID 设置为以下值之一:
"off"或0- 关闭规则"warn"或1- 打开规则作为警告(不影响退出代码)"error"或2- 打开规则作为错误(触发时退出代码为 1)
现在
npm i安装的eslint都是9的版本,目前我这边使用9版本后使用.eslintrc和.eslintignore配置在运行 eslint 检测的时候会提示已经不支持相关配置了。如果还是想使用之前的配置方式,安装 8 版本的即可(npm i eslint@8 -D)
eslint8 的配置
安装相关依赖
npm i eslint@8 @typescript-eslint/parser @typescript-eslint/eslint-plugin -D
// .eslintrc
{
"parser": "@typescript-eslint/parser",
"extends": [
"eslint:recommended",
"plugin:@typescript-eslint/recommended",
"plugin:@typescript-eslint/eslint-recommended",
],
"plugins": ["@typescript-eslint"],
"rules": {
// 相关规则
}
}
.eslintignore 配置里直接写忽略的文件夹和文件
node_modules
*.md
运行
在运行前,创建一个index.ts文件,输入测试内容
function a() {
console.log('eslint')
}
配置完后,可以直接在终端运行 npx eslint 检测的文件 执行,不过一般在 package.json 进行配置使用。
{
// ... 其他配置
"scripts": {
// ... 已有的配置
// 新增,--fix 表示自动修复问题
"lint": "eslint \"**/*.{ts,js}\" --fix"
// eslint8 配置
// "lint": "eslint ./ --ext .ts,.js,.json"
}
}
终端运行 npm run lint

说明 eslint 起到作用了
pretter
是什么
Prettier 是一个“有态度”的代码格式化工具,可以格式化代码,但不具备代码检查功能,它可以通过解析代码并使用自己的规则重新打印它,并考虑最大行长来强制一致的样式,并在必要时包装代码,如今,它已成为解决所有代码格式问题的优选方案,支持多种语言,可以将 ESLint 和 Prettier 结合使用,提高代码质量。
配置
下载相关依赖
npm i prettier eslint-config-prettier eslint-plugin-prettier -D
eslint-config-prettier 和 eslint-pulgin-prettier 插件是为了解决 prettier 和 eslint 冲突的。
在根目录添加新文件 .prettierrc
// .prettierrc
{
"semi": false,
"tabWidth": 2,
"singleQuote": true,
"printWidth": 100,
"trailingComma": "none"
}
然后再 eslint.config.mjs 配置中进行相关配置
// 其他引入
import eslintConfigPrettier from 'eslint-config-prettier'
import eslintPluginPrettierRecommended from 'eslint-plugin-prettier/recommended'
export default [
// 其他配置
eslintConfigPrettier,
eslintPluginPrettierRecommended,
// ...
]
eslintrc 中的配置
// .eslintrc
{
"extends": [
// 其他内容
"prettier"
],
"plugins": [
// 其他插件
"prettier"
],
"rules": {
"prettier/prettier": "error", // 打开 prettier 插件提供的规则,该插件从 ESLint 内运行 Prettier
// 其他 rules
}
}
运行
配置相关 scripts
{
// ... 其他配置
"scripts": {
// ... 已有的配置
// eslint
"lint": "eslint \"**/*.{ts,js}\" --fix",
// 新增配置
"format": "prettier --write ."
}
}
我们就可以进行测试了,在终端执行 npm run format

这是我们可以在 index.ts 中的代码语句中输入;再执行,会发现;会被清除

husky
已下操作涉及到 git 的使用
是什么
husky 是一个用于管理Git钩子的工具,它可以在代码提交、代码推送等Git操作前或后执行预定义的脚本。通过husky,可以在团队项目中强制执行代码规范、代码检查、单元测试等操作,以确保团队代码的质量和一致性
配置
首先我们来安装 husky 等相关依赖
npm install husky -D
# 安装完后执行
npx husky init
在
npx husky init之前,我们要先进行 git 初始化,终端运行git init
执行完后会看到根目录下会新建一个 .husky 文件夹,里面也会有个自动创建的文件 pre-commit
修改 pre-commit 中的内容
// pre-commit
npm run format
设置之后,我们在提交 git commit -m "test: 测试pre-commit",会发现husky会拦截代码日志提交,在进行了 npm run format 后再进行。

lint-staged
是什么
通常 husky 与 lint-staged 搭配使用,lint-staged 用于仅对添加到了暂存区的文件校验,避免了不必要的每次提交时全局校验。
配置
安装
npm i lint-staged -D
下载后可以直接在 package.json 中配置
{
"scripts": {
// ...
// 新增
"lint:lint-staged": "lint-staged"
},
"lint-staged": {
"**/*.{ts,js}": [
"npm run lint",
"npm run format"
]
},
}
这个配置可以在提交信息的时候记进行 eslint 检测和格式化代码。
pre-commit 文件中修改提交运行的指令
npm run lint:lint-staged
commitlint
是什么
CommitLint 是一个帮助你规范化提交信息的工具。
配置
# 下载相关依赖
npm i @commitlint/cli @commitlint/config-conventional commitizen cz-conventional-changelog -D
# 初始化配置
echo "export default { extends: ['@commitlint/config-conventional'] };" > commitlint.config.mjs
在 commitlint.config.js 中添加相关配置
export default {
extends: ['@commitlint/config-conventional'],
// 规则
rules: {
// 范围不能为 0
// 'scope-empty': [2, 'never'],
// subject 大小写不验证
'subject-case': [0],
// git 类型必须是以下类型
'type-enum': [
2,
'always',
[
'feat', // 新增功能
'fix', // 修复异常
'docs', // 更新文档
'style', // 代码格式(不影响功能,例如空格、分号等格式修正)
'refactor', // 代码重构(不包括 bug 修复、功能新增)
'perf', // 性能优化
'test', // 测试用例
'build', // 构建流程,外部依赖更改
'ci', // 修改 CI 配置,脚本
'revert', // 回滚
'chore' // 对构建过程或辅助工具和库的更改(不影响源文件、测试用例)
]
]
}
}
配置完后,我们要通过huksy来进行拦截。在 .husky文件夹中新建 commit-msg 文件
// commit-msg
npx --no -- commitlint --edit "$1"
完成到这里,我们提交信息的时候已经可以进行相关检测了。但是每次输入信息的时候都要按照相关要求输入会很麻烦,如果可以像初始化一样能够有选项提示,就更好了。
上面安装依赖中的commitizen和cz=conventional-changelog就是为了实现这一步的
根目录下创建 .czrc 文件
// .czrc
{
"path": "cz-conventional-changelog"
}
设置 scripts
{
// ... 其他配置
"scripts": {
// ... 已有的配置
"lint": "eslint \"**/*.{ts,js}\" --fix",
"format": "prettier --write .",
"lint:lint-staged": "lint-staged",
// 新增
"cz": "cz"
}
}
然后我们在进行 git add .后,可以运行 npm run cz 来代替 git commit操作

而后我们通过 git log 查看日志,可以看到是有相关记录的


浙公网安备 33010602011771号