关于前端:用魔法打败魔法前端代码规范化

目录

1. 工具简介
2. 实现思路
3. 具体实现
4. 总结
5. 附录

代码千万行，标准第一行。
编码不标准，共事两行泪。

早几年接手过一个我的项目，一堆 bug 不说，代码还又臭又长，据说之前写代码的那位仁兄常常改一个 bug 又带出十个 bug🌝我的项目里充斥着各种含意不明的变量、没有用到的不晓得从哪里复制粘贴过去的函数、乌七八糟的 console、得心应手的空行和毫无意义的正文……

很多程序员没有代码标准意识，常常感觉只有性能能用就行了，代码标准浪费时间，于是写进去的代码过一段时间可能连本人都看不懂是坨什么货色，更不用说接手的共事了。

今日便来说说，如何 从技术层面，实现代码标准以及代码提交标准。

1、工具简介

1. husky：一个 Git hooks 工具，能够让咱们在 git 提交前后进行一些操作，比方，在提交之前查看代码是否标准、进行对立的格式化解决、查看 git 提交的信息格式等等；
2. eslint：一个用 NodeJS 写的 Javascript 代码查看工具，可自定义规定；
3. lint-staged：一个可能只对 git 变更文件进行代码查看的工具；
4. commitizen：一个提供了交互式命令，可用于标准 git commit 信息的工具。

以上就是咱们这次要用到的四个工具。

2、实现思路

咱们能够通过 husky 提供的钩子(hooks)：

• 在 git 提交前，应用 eslint 或者 lint-staged 对代码进行查看，并进行对立的格式化解决；
• 在 git 提交时，查看 git commit 的格局是否符合规定；同时，应用 commitizen 实现命令行交互，来辅助咱们生成合规的 git commit。

3、具体实现

3.1 husky

装置：

yarn add husky -D

在 package.json 的script中增加：

"scripts": {"prepare": "husky install"}

prepare是 npm 的生命周期脚本。

当执行 npm install 的时候，就会主动执行脚本内容 husky install，从而在以后我的项目的根目录下生成.husky 文件夹。

这里的 husky.sh 配置次要是为了获取 hook 的执行后果，当执行过程中出错时，就退出过程。

接下来就能够欢快地应用 git hooks 啦。

3.2 hook：pre-commit

命令行执行 yarn husky add .husky/pre-commit 生成 pre-commit 脚本（当然也能够手动）：

#!/bin/sh
. "$(dirname"$0")/_/husky.sh"

undefined

稍作批改，来验证下在 git commit 的时候是否执行了这个脚本：

#!/bin/sh
. "$(dirname"$0")/_/husky.sh"

echo "commit 之前执行"

命令行 git 提交代码：

git add .
git commit -m”add husky config”

能够看到 pre-commit 脚本执行胜利，打印出了语句。

3.3 在 pre-commit 里增加 eslint 查看

装置：

yarn add eslint —dev

装置实现后，执行

yarn run eslint —init

或

./node_modules/.bin/eslint —init

执行实现后会主动在根目录生成 eslint 配置文件.eslinttrc.js。

批改pre-commit，增加 eslint 格局查看：

#!/bin/sh
. "$(dirname"$0")/_/husky.sh"


echo "eslint 格局校验" && ./node_modules/.bin/eslint src/*

能够看到，eslint 检测出代码里有 2 个 error 和 1 个warning。

error 是必须批改的，能够应用 eslint --fix 主动修复，并执行 git add . 把 fix 后的变更也增加到 git 缓存区：

#!/bin/sh
. "$(dirname"$0")/_/husky.sh"

echo "eslint 格局校验"

./node_modules/.bin/eslint src/* --fix # 对 src 下的所有文件作 eslint 查看，并用 --fix 修复 error

git add . # 将 eslint 的 fix 内容也增加到 git 提交中

测试一下：

胜利！

提醒：如果应用的是 Github Desktop 这类的图形工具，有可能会呈现上面这个谬误——

这是因为咱们只在我的项目里装置了 eslint，当在软件上运行的时候就有可能呈现门路谬误，只须要全局装置一下 eslint 就能够了：

yarn add eslint -g

下面的 eslint 查看脚本会对 src 中的所有文件进行查看。如果是一个新我的项目还好，如果是一些老我的项目，那么波及到的变更文件就会很多。

如果不想每次都全量检测，那么能够通过 git diff 来获取到变更的文件：

批改 pre-commit：

#!/bin/sh
. "$(dirname"$0")/_/husky.sh"

echo "eslint 格局校验"

arr=`git diff --name-only  HEAD` # 查看变更文件
for filepath in ${arr[@]}
do
    if [["$filepath" =~ ^[src/] ]]; then : # 只检测 src 下被批改的文件的格局
        if [-f "$filepath"];then # 只对存在的文件进行 fix，跳过 delete 的文件
            echo $filepath
            ./node_modules/.bin/eslint $filepath --fix
            git add $filepath
        fi
    fi
done

这段代码实现了：只对 src 中 有变更且非删除的文件 进行 eslint 检查和 fix。

这里举荐一个工具，也就是下面提到的 lint-staged，也能实现同样的性能，应用起来 更简略。

执行 npx mrm@2 lint-staged，能够看到package.json 中多了对于 lint-staged 的配置：

批改一下：

"lint-staged": {"src/*": "eslint --fix"}

pre-commit 改为：

#!/bin/sh
. "$(dirname"$0")/_/husky.sh"

echo "eslint 格局校验"

npx lint-staged

测试一下：

胜利！

至此，咱们就实现了根本的代码标准配置。

eslint 的具体配置参数这里就不开展了，感兴趣的同学能够去官网上自行摸索。

3.4 用 commitizen 标准 git commit

装置：

npm install --save-dev commitizen

在 package.json 中配置：

  "scripts": {"commit": "cz"},
  "config": {
    "commitizen": {"path": "cz-conventional-changelog"}
  }

测试一下：

留神，这里就不能用 git commit 了，而要用 yarn run commit 或npm run commit，执行后命令行里会呈现一些交互选项，来帮忙咱们生成 git commit。

看不习惯英文的也能够装置中文包：

yarn add cz-conventional-changelog-zh

commitizen只能帮忙咱们生成标准的 git commit，如果有些队友忘了应用 yarn run commit，而间接用 git commit -m”xxx”写了不标准的提交信息，怎么办？

还记得下面说的 husky 吗？咱们能够通过 husky 的 commit-msg 钩子来校验 git commit 的提交信息。

3.5 hook：commit-msg

yarn husky add .husky/commit-msg

批改 commit-msg：

#!/bin/sh
. "$(dirname"$0")/_/husky.sh"


commit_regex='^Merge.+|(feat|fix|docs|style|refactor|perf|test|build|ci|chore|revert|types)(\(.+\))?: .{1,50}'


if ! grep -iqE "$commit_regex" "$1"; then

echo
echo "commit 信息格式谬误！！"

echo "格局应为：[Type]: [Summary]"

echo "Type 可选值为 Merge|feat|fix|docs|style|refactor|perf|test|build|ci|chore|revert|types"

echo "留神两头的空格"

echo "示例：git commit -m \"test: add something test\""

echo
exit 1

fi

测试一下：

功败垂成！

4、总结

标准的代码不仅能缩小合并抵触，还有助于进步代码的可读性，升高之后的保护老本。

对团队而言，有可能是铁打的代码流水的程序员，前人留下的坑得前人去填，标准代码是十分必要的。

对集体而言，标准的代码不仅能缩小 bug 的呈现，还有助于更好地了解编程语言的个性，成长有时候就是这些细节处的积攒。

技术上只能起到一部分的标准作用，更重要的还是意识上的主观能动性，只有意识到代码标准的重要性，能力真正实现我的项目的代码规范化。

附录

• husky
• eslint
• lint-staged
• commitizen
• airbnb 代码标准