background

In a conscientious brick-moving operation, encountered a common problem:

Tslint, which was configured in the project’S CI flow, triggered automatically after my buggy git push code, and unfortunately it was blocked. Blocked ruthlessly by tsLint.

Troubles come

Here comes my dilemma:

  • TsLint prompts code style error! Need to rework
  • Prettierrc, eslintrc the local vscode does not match the tslint configuration, and the project does not have a. Prettierrc, or.eslintrc properly configured locally
  • The time of rework is slightly late

Face a choice

In fact, I have three choices at this point:

  1. Local fix: Close the local VScode prettier tool and modify the file “code style” until it passes
  2. Prettier: Take the time to configure the local prettier tool as tsLint does
  3. Configure team tools: Configure automatic formatting tools to ensure that the project automatically optimizes the code style each time it is submitted

In consideration, we are going to optimize it into a team tool that bypasses existing TSLint and helps you standardize Lint.

I think the advantages of this scheme are as follows

  1. Potential code style problems can be found at Git commit time without rework after push
  2. Automatic formatting
  3. Configuring Shareability

Here’s a look at the tools used:

Tools list:

  • husky
  • lint-staged
  • eslint
  • commitlint

Add an A.js to the project; For later tests;

let a=1;
let b=2;
Copy the code

Husky use

Husky version 4.2.5 is used here.

NPM [email protected] - I DCopy the code

Configure the information in pacakge.json

{
  "name": "projectName",
  "description": "",
	"husky": {
    "hooks": {
      "pre-commit": "echo 111",
    }
  }
}
Copy the code

Git commit -am ‘husy test’ git commit -am ‘husy test’

Husky successfully registered git hooks!

lint-staged

A tool is installed that can process the file selected by the re.

For example, in all submitted files, I have different lint operations on CSS and JS, which can be distinguished by *.js or *.css

yarn add lint-staged -D
Copy the code

Add configuration in package.json file

{
	"lint-staged": {
    "*.js": "echo 222"
  }
}
Copy the code

Try adding the file A.js and performing git commit -am ‘Lint-staged’

The output of the pre Commit hook & the operation on js was successful;

eslint

This step is pretty easy.

yarn add eslint -D
Copy the code

Let’s do the esLint initialization again

eslint --init
Copy the code

Modify our package.json at this point

{" name ":" autolint - demo ", "version" : "1.0.0", "description" : ""," main ":" index. Js ", "scripts" : {" test ": "echo "Error: no test specified" && exit 1", "lint": "eslint --fix" }, "keywords": [], "author": "", "license": "ISC", "devDependencies" : {" eslint ":" ^ 7.32.0 ", "husky" : "4.2.5," "lint - staged" : "^ 11.2.0"}, "husky" : {" hooks ": { "pre-commit": "lint-staged" } }, "lint-staged": { "*.js": "npm run lint" } }Copy the code

Run the commit command; You can see that the corresponding places in the A.js file will be prompted by ESLint;

Install an Airbnb code style

Installation:

npx install-peerdeps --dev eslint-config-airbnb-base
Copy the code

. Eslintrc. Js configuration:

module.exports = {
  env: {
    browser: true,
    es2021: true,
  },
  extends: "airbnb-base",
  parserOptions: {
    ecmaVersion: 12,
    sourceType: "module",
  },
  rules: {},
};
Copy the code

At this point, automatic ESLint formatting ~ can be done at commit time

Add a submission specification tool

Installation:

yarn add  @commitlint/config-conventional @commitlint/cli -D
Copy the code

Local configuration file commitlint.config.js

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

After the installation is completed, the submission is rejected.

Because the submission needs to comply with the response specification;

Specification address: www.npmjs.com/package/@co…

perform

git commit -am 'feat:  new commit for new commit lint'
Copy the code

At this point, a regularable project is complete;