前端项目规范化工具
1. ESlint
Lint 是一类专门用于检查代码的工具软件， 也称 linter。ESLint ，即 JavaScript （ECMAScript）代码的检查工具。
正如官网的介绍 —— “Find and fix problems in your JavaScript code”，ESLint 能够辅助查找出你的 JavaScript 代码中的问题，包括：
- 代码风格问题（styles）。比如，运算符两边的空格、语句末尾的分号。
- 不好的写法。比如，使用 == 进行比较而不是 ===。
- 可能存在逻辑问题的代码模式。比如，定义了一个变量，但没有使用到它。
此外，ESLint 还能够帮你自动修复一些简单的问题。
2. Prettier
它是一个代码格式化工具
Prettier vs ESLint
你可能好奇 Prettier 和 ESLint 有什么区别？
首先，虽然它们都会对代码 AST（语法树）进行检查，但 Prettier 只会进行语法分析，只能检查并归正代码的格式问题，而 ESLint 还会进一步对代码进行语义分析，能发现格式问题和代码模式问题。比如，用 let 声明了一个变量，但是这个变量在后面并没有被重新赋值，因为没有格式问题，Prettier 会通过，而 ESLint 则能发现这里应该使用 const 声明更好。
既然 ESLint 也能做格式化工具，那为什么还需要 Prettier？因为 ESLint 只能检查 JavaScript 代码以及 TypeScript、JSX 等衍生代码（需配置解析器），无法检查项目中的 CSS、HTML 等代码。Prettier 则天然支持对大多数项目文件的格式化，包括 JSX、Vue、TypeScript、CSS、HTML、JSON、Markdown、YAML 等。
同时使用 Prettier 和 ESLint
从上面可以看出，在 JavaScript 及其衍生语言的格式化上，ESLint 和 Prettier 是有重合的。所以，在实际运用中，我们需要保证这些文件只会采用其中一种进行格式化，避免不必要的格式化。更遭的情况是启用了两个，而且两个工具的风格配置互相冲突。我就曾在项目中遇到这种情况，ESLint 格式化之后，Prettier 也执行格式化，结果 ESLint 检查还是不通过。
推荐在 JavaScript 中也使用 Prettier。因为 ESLint 需要我们把风格配置成 error 等级，才会支持自动修复。但是，这样，一旦有格式问题，编辑器就会标红，很烦人，强迫症受不了，而 Prettier 不会有。
要同时使用二者，就需要关闭 ESLint 中可能和 Prettier 冲突的规则，而这就是 eslint-config-prettier 所做的事。所以，想同时使用两者，你需要在 ESLint 中使用该配置，具体的配置方式参考使用文档即可。
如果你只想在 JavaScript 中使用 ESLint，可以在 .prettierignore 中忽略所以的 JavaScript 文件即可。
3. Stylelint
Stylelint 就是样式代码的 linter。
它的功能和使用，都和 ESLint 类似，不过作用目标不同而已。
和 Prettier 的区别在于，它和 ESLint 一样，是一个 linter，会进行语义分析，能发现一些模式问题。在 Stylelint 15 之前，如果同时使用 Stylelint 和 Prettier，也需要使用 stylelint-config-prettier 避免在样式文件上的规则冲突。Stylelint 15 废弃了所有风格规则，不会和 Prettier 冲突。
4. 工作流工具
将 linter/formatter 与一些工作流工具配合，能够实现团队规范的自动化。
规范化原则是：越早发现不规范的代码，改正的成本越低。
1. 编码时：编辑器支持
从编码开始，就推荐你启用编辑器的代码检查功能，这可能是需要插件或者设置来实现。同时，建议开启保存时自动格式化，这能持续保证你的代码是符合规范的。
2. 提交时：Git hooks + lint-staged
Git pre-commit hook 可以让我们在提交之前执行一些命令，利用这点，可以在提交前对代码执行代码的 lint 检查和格式化，自动修复一些可以修复的问题，如果有不可自动修复的问题，取消本次提交，从而，避免不规范的代码被提交到代码仓库。
默认的 Git hook 不容易设置，社区中流行使用 husky 进行配置。
每次提交时的检查应该是针对当前 commit 内修改的内容，而不是全部文件，也就是只检查暂存区内的文件。lint-staged可以实现这种效果。
3. 交付时：CI 集成
pre-commit 检查可以通过 git commit --no-verify 跳过，导致一些不规范的代码被 push 到代码仓库。
可以通过 Gitlab-CI 或 Github Action 这类 CI 工具集成代码检查，在代码被 push 到远程仓库，或者 merge request 发起时，执行特定的任务对代码发起检查。
值得一提的是，CI 集成可以是整个代码仓库统一的，这样，可以实现公司层面的所有项目统一标准，而不只是基于团队和项目。
5. 其它工具
1. commitlint：规范提交消息
commitlint - Lint commit messages 是规范提交消息（commit message）的一个工具，可以避免有些小伙伴就喜欢 git commit -m "u"，要求一个提交消息符合 Conventional Commits规范，即以下形式：
<type>[optional scope]: <description>
[optional body]
[optional footer(s)]
commitlint 本身是一个命令行工具，用于判断一个消息是否符合规范。
# Lint from stdin
echo 'foo: bar' | commitlint
⧗ input: foo: bar
✖ type must be one of [build, chore, ci, docs, feat, fix, perf, refactor, revert, style, test] [type-enum]
✖ found 1 problems, 0 warnings
ⓘ Get help: https://github.com/conventional-changelog/commitlint/#what-is-commitlint
为了实现在 commit 时检查消息，需要和 git commit-msg hook 配合。配合上面提到的 husky：
npx husky add .husky/commit-msg 'npx --no -- commitlint --edit ${1}'
2. branch-name-lint: 规范分支名
如果希望规范团队项目中的分支名称，可以使用 branch-name-lint。
一般地，项目只需要规范成员 push 到远程仓库的分支名称符合规范即可，不限制本地分支。按这个思路，可以利用 git pre-push hook：
npx husky add .husky/pre-push 'npx --no -- branch-name-lint <your-configuration.json>'
3. EditorConfig: 统一编辑器配置
EditorConfig是一个跨编辑器/IDE 的编辑器配置工具。与 linter 和 formatter 不同，它的作用对象不是代码，而是去约束编辑器的配置，比如缩进风格是 tab 还是空格，缩进多少个字符。同时也说明，它是作用于文件级别的，对代码语法是无感的，对所有文件都生效。
许多编辑器都支持 EditorConfig，有的可能需要安装插件，不需要项目安装什么依赖包，只需要在根目录下创建一个 .editorconfig 文件。
EditorConfig 适用于团队成员中使用不同编辑器的场景。当所有编辑器都使用项目根目录下的 .editorconfig 文件作为配置时，能一定程度上保持代码文件的统一性。
总结
前端工程化的常见代码规范工具有：
- ESLint: 一个用于 JavaScript、JSX 等语言的可配置的代码检查工具。
- Stylelint: 一个 CSS/Less/Sass 等样式代码的 linter。
- Prettier: 支持多种语言的代码格式化工具。
- Husky: 一个流行的用于配置 git hooks 的工具。
- lint-staged: 对提交到暂存区的文件进行检查的工具。
- EditorConfig: 统一不同编辑器配置的工具。
- commitlint: 检查提交消息是否符合规范。
- branch-name-lint: 检查代码分支是否符合规范。