React App Framework - 2. Lint

背景

在多人合作项目中, 代码风格统一是一个重要的问题. 否则合作开发时提交信息会非常混乱. 而create-react-app自带的ESLint规则又比较弱, 而且缺少代码格式的检查, 所以我们需要加上prettier来检查代码风格, 同时再使用husky,commitlint和lint-staged来实现提交前的代码检查hook

配置

prettier

prettier的ESLint配置比较简单, 在package.json里加上对应的配置即可

{
  "eslintConfig": {
    "extends": [
      // ...
      "prettier"
    ],
    "rules": {
      "prettier/prettier": "error"
    }
  },
  "prettier": {
    "printWidth": 150,
    "singleQuote": true,
    "trailingComma": "all",
    "arrowParens": "always",
    "jsxSingleQuote": true,
    "endOfLine": "lf"
  }
}

husky

这个只需要注意在script里加上"postinstall": "husky install", 实现自动安装就行

commitlint

同样在package.json里添加配置

{
  "commitlint": {
    "extends": ["@commitlint/config-conventional"]
  }
}

lint-staged

还是在package.json里添加配置

{
  "lint-staged": {
    "{src,test}/**/*.(tsx?|js)": ["eslint --fix"],
    "*.{css,md,yml}": ["prettier --write"],
    "*.md": ["prettier --write"]
  }
}

其他

引入其他比较流行的ESLint插件和规则集合后, 会出现一些常见的写法出现warning的提示, 如果综合考虑后决定不修复, 在ci编译的时候, 由于CI=true, 会导致打包报错, 有两个方法解决

1. 通过package.json里的eslintConfig.rules配置将该规则禁止

2. 在gitlab-ci文件中覆盖该环境变量(不推荐)

   variables:
     GIT_SUBMODULE_STRATEGY: recursive
     CI: ''

小结

这篇内容比较短, 以为网上资料都比较全面, 复杂的部分是全部结合起来并且在项目中探索适合各自项目组的配置, 并且处理好落地过程中的一系列小坑