Build unified code style and code inspection workflow to improve front-end application quality and code maintainability

background

Code quality and style are very important for large and mid-range front-end projects with multiple people involved, and developers expect it to be straightforward and comfortable, not a dizzying “Shi Shan” when you refactor or take over someone else’s work. For the team, good code quality can reduce product defects, and consistent code style can improve team development efficiency. So, how to ensure the team code quality and style, in other words, through a friendly, efficient, not to bring extra burden way of automation to fall to the ground, to share my own practice, may be retained in the code, the code is submitted, three phase when the code package to check/control by different means, The goal is to implement an automated code review workflow.

The plugin is introduced

Plug-in installation/configuration can be once, plug-in details can be baidu

“Eslint “: javascript code detection tool” eslint-plugin-vue “: ESLint for VUE “stylelint”: CSS detection tool “stylelint-config-standard”: Recommended configuration for stylelint “stylelint-ORDER “: CSS property sorting plug-in, reasonable sorting to speed up page rendering” stylelint-SCSS “: added support for SCSS syntax

First level, save: vscode plugin eslint+stylelint

Solve the pain point: IDE automatically formatting code when saving, save time, energy and efficiency

The editor can read the ESLint /stylelint configuration file and display a red wavy line if it does not conform to the specification. You can configure CTRL + S to automatically format the js and CSS parts of the current file when saving, but errors such as defining a variable that is not used cannot be automatically fixed.

Json {"eslint.format.enable": true, // Save to format "editor.codeActionsOnSave": {" source.fixall. eslint": true, "source.fixall. stylelint":true}, // Automatic formatting paste code "files.autoSave": "afterDelay"}Copy the code

Stage 2, when submitted: Husky + Lint-staged + ESlint /stylelint –fix

Fix the pain points: Instead of running the CI pipeline to discover code problems, expose them before committing locally

NPM install husky Lint-staged -- save-devCopy the code

The Husky plugin (nodejs 10.6 and above) can set up git hooks to execute scripts before you commit

  "husky": {
    "hooks": {
      "pre-commit": "lint-staged"
    }
  },
Copy the code

Lint-staged plug-ins can only scan files that Git Add into the stage area, so that each person can only scan and fix the incremental code he or she is about to commit

 "lint-staged":{
     "*": [
       "stylelint --fix",
       "eslint --fix"
     ]
  },
Copy the code

Through cooperation between Husky and Lint-staged episodes, each commit will be checked and automatically formatted. If there are errors that cannot be automatically fixed, the COMMIT will be stopped, and the error location can be seen at the bottom output for manual repair and re-submission

Why not a full scan?

  1. If you are maintaining an old project, or if you did not introduce code reviews at the beginning of the project, a large number of errors will be reported when you suddenly perform a full review
  2. Everyone is only responsible for changing their own code, so as not to affect the rest of the code, as the project progresses, as long as the changed code will be checked.
  3. It is recommended to arrange for a full scan and a full repair early in the project, after which only incremental code scans are required.

The third level, when packaging: CI pipeline added code scanning

Pipelinesonar code is added to scan and set threshold blocks

Existing problems:

1, need to execute the assembly line to find the problem. Sonar rules not completely consistent with ESLint rules * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

Conclusion:

1, as long as can achieve 1, 2 levels should be used, efficient and elegant, and do not waste CI resources. 2. For old projects that cannot be realized, use the third line code for quality detection and control. 3. This paper focuses on the practical ideas and methods of integrating code inspection and control into the workflow. For the mentioned plug-ins that are not clear enough, they can be baidu by themselves, and different technology stacks will also be different.

Copyright belongs to the author. Commercial reprint please contact this account for authorization, non-commercial reprint please indicate the original address.