敞开掘金生长之旅！这是我参加「掘金日新方案 12 月更文应战」的第2天，点击查看活动概况

前言：为了确保团队的代码质量，我给加了许多的约束。 经过这些约束，能够主动依据某些规矩，主动格局化不符合标准的代码。并对代码进行检测，以及为了未来更清晰的git提交信息，还对git commit信息进行了格局约束。

为什么要这姿态做

我了解的代码质量分为许多方面，比方代码可读性，代码健壮性（防止过错）以及代码风格。

代码健壮性方面，在写的时候，就尽或许的躲避或许出现的过错，岂不美哉！！

代码风格方面，就像“一千个读者眼中就会有一千个哈姆雷特”相同，或许每个人写代码的风格都不相同。也难以说什么好与坏，究竟代码能跑就行（）。当然，假如这么想，或许会被你亲爱的搭档们锤爆。在多人开发中，团队一般都会确保代码风格尽量共同。究竟谁不喜爱好看且风格共同的代码呢？除非要自己写。

所以，为了躲避这些问题，运用了一系列的东西来支持。

怎样做

这儿介绍下，为了完成自己想要的功用，我是怎么做的。

方针：

  1. 代码查看防止过错
  2. 保存代码主动格局化不标准代码
  3. 对commit信息进行标准约束

为了完成自己的功用，我运用ESLint并运用社区运用比较多的standard规矩进行代码查看，防止报错，运用Prettier进行代码格局化。

调配husky + lint-stage在git提交时，进行代码主动操作。

并运用commitlint对git提交信息进行标准约束。

包安装

// eslint
npm i -D eslint
// eslint-config-standard
npm i -D eslint-config-standard eslint-plugin-promise eslint-plugin-import eslint-plugin-n
// prettier
npm install --save-dev prettier eslint-plugin-prettier eslint-config-prettier
// husky + lint-staged
npx mrm@2 lint-staged
//commitlint
npm install -D @commitlint/cli @commitlint/config-conventional
npx husky add .husky/commit-msg 'npx --no-install commitlint --edit "$1"'

配置文件增加

eslint

// .eslintrc
// 运用standard规矩进行代码查看
// 让eslint运用prettier规矩进行格局化
{
    "parser": "@typescript-eslint/parser",
    "extends": [
        "standard",
        "prettier"
    ],
    "plugins": [
        "prettier"
    ],
    "rules": {
        // https://github.com/prettier/eslint-plugin-prettier#recommended-configuration
        // prettier配置，让eslint运用prettier的规矩进行代码格局化
        // 将error改为off，无感运用prettier格局化，想看到，能够走官网引荐的error
        "prettier/prettier": "off",
        "arrow-body-style": "off",
        "prefer-arrow-callback": "off",
        // 未运用变量正告
        "no-unused-vars": "warn",
        // TODO:不允许在声明前运用，react引用会报错,先封闭
        "no-use-before-define": "off",
        // 封闭全局变量的显式声明
        "no-undef": "off"
    }
}

prettier

//.prettierrc
{
  "tabWidth": 2,
  "semi": true,
  "arrowParens": "avoid",
  "singleQuote": true,
  "trailingComma": "all",
  "bracketSpacing": true,
  "printWidth": 120,
  "bracketSameLine": true,
  "useTabs": false,
  "quoteProps": "preserve",
  "jsxSingleQuote": false
}

commitlint

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

package.json

{
"husky": {
    "hooks": {
      "pre-commit": "lint-staged",
      "commit-msg": "commitlint -e $HUSKY_GIT_PARAMS"
    }
  },
  "lint-staged": {
    "*.{js,css,json,md,jsx,ts,tsx}": [
      "prettier --write",
      "git add"
    ]
  }
}

调配vscode

插件引荐： 确保代码质量插件包(夹藏私货，引荐安装包内相关vscode插件，或许直接安装我的插件包)

作业区文件增加

// .vscode/settings.json
{
  // 每次保存的时候主动格局化
  "editor.formatOnSave": true,
  //回车主动格局化
  "editor.formatOnType": true,
  // 主动调整 import 句子相关次序，能够让你的 import 句子依照字母次序进行排列
  "editor.codeActionsOnSave": {
    "source.organizeImports": true
  },
  // 整个编辑器默许运用prettier进行格局化代码
  "editor.defaultFormatter": "esbenp.prettier-vscode",
}

总结

这儿仅仅提供了自己的解决方案，仅仅完成了功用。并没有对详细规矩做具体描绘，感兴趣的能够自行研讨下，相关资源在最下面。

最终想说，合适自己的才是好标准，每个团队的标准或许都或多或少会不同，这儿仅仅运用了standard的规矩防止报错，然后调配运用prettier格局化代码。亲们能够依据自己需求的不同，在extends增加eslint想要的规矩,也能够直接在rules中增加或许修正自己想要的规矩。

TODO

未来，进一步筛选规矩，并将stylelint也加进来！

最终

假如有不对的地方，欢迎纠正！一起欢迎一起评论！

项目开发时，我为保证团队代码质量做的那些事儿

相关资源

eslint

eslint-config-standard

prettier

你的ESLint真的需求Prettier吗？

commitlint