初次实践husky+lint工具合集-标准化工作流

前言

又抓住了11月的尾巴来更新文章了，今天想写一写关于工作中是如何实践前端标准规范化工作流的。

我们前端开发人员有7个左右，每个人的风格不一样，可想而知，如果没有标准代码提交规范，那可真是各色代码鱼龙混杂。思考过这个问题吗，只要放慢脚步，不再只关注于手头的工作，想想如果让你怎么去解决这个问题呢？😶‍🌫️

聚焦问题的中心，想想实现的目标是什么？💡

1.代码提交前按照规则格式化、语法校验，存在错误不再提交到仓库；
2.commit msg清晰，言简意赅，核心描述此次提交的内容；
3.每次发版可以生成changelLog，帮助查找每次迭代的更新内容；
4.最好每次提交前自动帮助我们做以上的工作，且具有强制性；

接下来的文章，不会具体讲解每个工具是如何使用，会将重点说明，它们->如何能帮助我们实践标准规范化的工作流。

husky

是不是任意一篇文章点开，就离不开这个主角呢？husky是结合git hooks实现在各种钩子中添加自定义命令，如test、eslint、commitlint等处理，官网上的一句描述了他的feature. 官网链接在这里

You can use it to lint your commit messages, run tests, lint code, etc… when you commit or push. Husky supports all Git hooks.

根据官网上的指导，就先初始化一个项目吧！

npm init // 初始化项目，并生成package.json
git init // 既然husky结合的是git hooks，当然要使用git管理仓库了 

接着往下，开始使用husky的魔法了

npx husky-init // modify `package.json` and create a sample `pre-commit` hook that you can edit. By default, it will run `npm test` when you commit. 

这条命令执行后，会修改package.json文件，并新增一条命令，"prepare": "husky install". 当前目录下也会生成.husky文件夹，用来存储使用的git-hooks命令.默认会有一条pre-commithook，代表在提交commit之前会执行. 后续里面的命令我们会替换成其他的。

continue，接着我们下载依赖，并添加一条commit-msghook，用来校验commit信息是否符合commitlint的规范。

yarn // 开始下载依赖
npx husky add .husky/commit-msg 'npx --no -- commitlint --edit "$1"' // add another hook 

lint-staged

如果使用eslint等代码校验工具，在每次保存或提交全局校验代码耗时就会非常长，而且如果别人的代码有错误影响提交，自己也不好去修改，万一下次就有冲突呢😶‍🌫️

lint-staged仅会对Git暂存区进行过滤符合我们设定条件的文件，eslint、prettier等再去格式化代码操作。

安装

npm install -D lint-staged 

修改package.json的配置

"scripts": {"test": "echo \"Error: no test specified\" && exit 1","prepare": "husky install","lint": "eslint . --ext js,jsx,ts,tsx,vue --fix"
 },
"lint-staged": {"src/*.{js,jsx,ts,tsx}": "npm run lint", // eslit校验，我这里都是配置的对src目录下所有符合条件的文件进行过滤"src/*.{js,jsx,tsx,ts,less,md,json}": ["npx prettier --write", // prettier格式化"git add"]} 

修改husky中pre-commithook的命令，即在提交前会执行lint-staged.

eslint

安装eslint相关依赖

npm install -D eslint eslint-config-prettier eslint-plugin-prettier eslint-plugin-vue 

配置.eslintrc.js文件

module.exports = {env: {browser: true,es2021: true},extends: ['plugin:vue/vue3-recommended','plugin:vue/vue3-essential','plugin:prettier/recommended', // eslint-plugin-prettier 会将 prettier 作为 ESLint 的规则来使用，相当于代码不符合 Prettier 的标准时，会报一个 ESLint 错误，同时也可以通过 eslint --fix 来进行格式化'prettier' // eslint-config-prettier 解决eslint与prettier的冲突，写在最后面会覆盖冲突的eslint规则],overrides: [],parserOptions: {ecmaVersion: 'latest',sourceType: 'module'},plugins: ['eslint-plugin-vue'], // 项目vue框架的化，这个插件会提供vue/vue3-essential、vue/vue3-recommended等校验规则rules: { // 放置自定义规则'no-unused-vars': 'error','no-console': 'error'}
} 

prettier

安装

npm install -D prettier 

配置.prettierrc文件，我这里配置的很简单，可以根据需要添加

{"semi": false,"tabWidth": 2, // tab长度为2"trailingComma": "none", // 句末分号"singleQuote": true, // 单引号"arrowParens": "avoid"
} 

commitlint

commitlint是用来规范提交信息的，规范的信息可以用来生成changeLog，在husky的commit-msghook里已经增加了commitlint命令，提交后会对我们输入的信息进行校验，如果不符合规范commit-msghook会抛出错误，commit会停止。

安装

npm install --save-dev @commitlint/config-conventional @commitlint/cli 

配置commitlint.config.js文件

module.exports = {extends: ['@commitlint/config-conventional']}; 

commitlint是有提交格式的，

git commit -m <type>[optional scope]: <description>

// 举个例子，如果我修改了一个bug，我会这么写
fix/(@gcbp/web-framework): 修复下拉选展示异常 

常用的type如下：

• build 编译相关的修改，例如发布版本、对项目构建或者依赖的改动
• chore 其他修改, 比如改变构建流程、或者增加依赖库、工具等
• ci 持续集成修改
• docs 文档修改
• feat 新特性、新功能
• fix 修改bug
• perf 优化相关，比如提升性能、体验
• refactor 代码重构
• revert 回滚到上一个版本
• style 代码格式修改, 注意不是 css 修改
• test 测试用例修改

总结

到目前为止，回顾开头的目标，我们使用了husky管理git hooks强制性在提交文件阶段做了两件事，在commit-msghook使用commitlint规范commit信息，并且有严格清晰的格式规则；在pre-commithook使用lint-stages将暂存区文件，小范围内进行格式化，使用eslint校验代码，prettier格式化代码，保证参与项目每个人的代码风格一致。

可以尝试按照文章的步骤从0开始，看看效果吧，这样记忆会更加深刻💕

最后

整理了75个JS高频面试题，并给出了答案和解析，基本上可以保证你能应付面试官关于JS的提问。

有需要的小伙伴，可以点击下方卡片领取，无偿分享