EditorConfig

基本上目前所有编辑器都支持地很完善，拿 vscode 来说，prettier 的配置文件是需要装插件 + 做一定的编辑器设置的。而 editorconfig，装完 EditorConfig for VS Code 就可以了（WebStorm 默认支持），能够很方便地覆盖编辑器的默认格式化。所以它的主要好处其实就在这里，编辑器的默认格式化不同于通过快捷键调用类似 prettier 的三方格式化工具，它能够在比如新建文件，回车换行的阶段就保持正确的代码格式。

ESLint + Prettier

prettier 解决的是各种代码格式问题，eslint 解决的是 js 格式 + 代码质量问题，故推荐二者结合起来用去解决各种代码格式 + js 质量问题。但因为二者都可以对 js 代码进行格式化，所以可能会出现规则冲突，比如 eslint 要求有分号，prettier 要求没分号，这种时候就需要 eslint-config-prettier 来覆盖掉 eslint 规则中与 prettier 冲突的部分。最后既然两个都用了，难道每次都得执行一遍 eslint，再执行一遍 prettier 吗？所以又有了 eslint-plugin-prettier，通过它可以只执行 eslint，eslint 再帮你执行 prettier。

PS：目前已不推荐使用 tslint，可以通过 typescript-eslint 让 eslint 支持 TypeScript。其实理论上所谓的支持 TypeScript，支持的其实只是 Type Recommend 部分，比如推荐使用 interface 而不是 type，async 函数推荐返回 Promise 等这些类型的质量或风格的约束，至于把一个 number 赋值给 string 这种对于 ts 来说其实就等于是语法错误，ts 编译器就直接给报错了，而不是 lint 工具干的事情。

lint 配置示例：

1
2
3
4
5
6
7
8
9
10
11
12
13
{
  "parser": "@typescript-eslint/parser",
  "plugins": ["@typescript-eslint"], // 和 parser 一起让 eslint 支持 ts 和 tslint 的相关规则
  "extends": ["react-app", "plugin:prettier/recommended"], // 使支持jsx 以及 prettier
  "parserOptions": {
    "ecmaFeatures": {
      "legacyDecorators": true // 如果使用 decorator 得开启该项
    }
  },
  "rules": {
    // 一些个性化的规则
  }
}

Husky + LintStaged

如果在开发阶段开启了 lint 检查是件很苦恼的事情，尤其是加入了 TypeChecker 的 ts 项目，耗时且费心，很多时候会为了不让 lint 报错而需要手动去来回注释掉一些待会可能会用到的代码。为了解决这个问题，commit 阶段再执行代码检查的方案应运而生：只要能够保证最终提交到仓库的代码是符合规范的，在本地随你怎么浪。然后就有了 husky 来提供一系列的本地 git hook 来支持你做这些事情。

不过追求极致的工程师们又发现这样每次提交的时候都执行全量 lint 还是太浪费时间了，如果能每次只 lint 提交的部分那该多清真！于是又有了 lint-staged 来搞这件事情。

但喜欢搞事情的工程师们又觉得每次检测完错误，还得手动地去报错文件里一个个地执行修复（一般是敲个快捷键）很傻，反正大部分规则都是支持 autoFix 的，所以可以在 lint-staged 的 eslint 命令结尾处加个 ‘–fix’。

不过需要注意的是，毕竟是本地 hook，难免会有把 hook 关掉的风险，所以线上仓库在合并阶段的 lint 必须得有，作为最终的风格保障！这个一般代码托管平台都提供了相关的 WebHooks，可以基于它来实现。

package.json 中的配置示例：

1
2
3
4
5
6
7
8
9
10
{
  "husky": {
    "hooks": {
      "pre-commit": "lint-staged"
    }
  },
  "lint-staged": {
    "src/**/*.{js,jsx,ts,tsx}": ["./node_modules/.bin/eslint --fix", "git add"]
  }
}

 上一页

 评论