First of all, there were several code conflicts and coverage problems caused by different IDE formatting, which had a great impact on the collaborative development of the team. The waste of time to solve the conflicts also led to the latest code being covered

As one of them, I was also very annoyed. After I raised the problem to the leader, the task of solving the specification was assigned to me. Although I didn’t know much about related content except ESLint, I still have a deeper understanding of code specifications and Git.

Through reviewing the cases of other companies formulating norms and my own thinking, I concluded three aspects of the implementation of norms from my own ideas, including:

  • Code Style Verification (ESLint)
  • IDE formatting (ESLint, Vetur)
  • Git pre-commit Hook

The three are combined to form a process with ESLint at its core.

A code style verification tool

As a validation tool for the js core, ESLint is also part of the specification core. In fact, it has been used in the company project, but due to historical reasons, it uses the Airbnb-Base specification that only verifies JS, while the front-end project technology stack is VUE. Even with the vetur plug-in on VSCode, ESLint can only verify JS code inside script tag. The code in the Template template is basically free to operate without any rules. A common example is when a component has too many bound properties, resulting in a single line of code that grows out of the sky and makes the code very unreadable.


In fact, esLint now adds plugin:vue/essential/eslint-plugin-vue for template sections in vue files. For details, see the rule list in the documentation.



Eslint-plugin-vue is automatically installed in vuecli3 projects if esLint validation is selected at creation time. It can expose the formatting errors of most template code blocks to users, such as the repeated declaration of key attributes, which can solve the problem of inconsistent style of some template code.

Second, IDE formatting plug-in

As mentioned in the previous section, ESLint helps solve most code problems. However, there are still some practical problems. For example, when code does not conform to ESLint rules, can it be automatically formatted to conform to the rules? For example, vscode, the most commonly used plug-in, provides a plugin with the same name as eslint, which can automatically modify sections of code that do not conform to eslint rules when pasting or saving code. To do this, you need to download the plugin and add the following configuration to the VScode configuration file setting.json.


{
  "editor.formatOnSave": true// The editor formats the code when it is saved"eslint.autoFixOnSave": true, // esLint formats code when saved // The language in which esLint formats is applied"eslint.validate": [
   "javascript"."javascriptreact",
   {
     "language": "html"."autoFix": true}, {"language": "vue"."autoFix": true,}}]Copy the code



When configured, the ESLint plugin automatically formats the code when it is saved. But in practice, formatting is not enough. For example, the single line of code is too long, and formatting still does not wrap the code. Most recommended rules are vue/max-attributes-per-line rules that automatically wrap tags with multiple attributes. Try the Strongly Recommended rule in eslintrc.js


extends: [
  'plugin:vue/strongly-recommended'.'@vue/airbnb',].Copy the code


It works, but it’s not formatted as expected.


Before formatting, the code looks like this,


After formatting, it becomes the following strange appearance.

There is an article on stack overflow that explains this problem. The general reason is that eslint formatting some rules takes several times to complete, whereas vscode eslint only formats once when it is saved, without going through the formatting process. As you keep saving code, ESLint will continue formatting step by step until the formatting is complete and looks like this.


We have to mention the plug-in Vetur that vue developers are very familiar with. In previous development, I only used syntax highlighting and attribute association, but in fact it can use different formatting tools for each block of code such as Template, script, and style to achieve the same purpose.

First follow the steps below to enter the configuration page of the Vetur plug-in.



It lists the formatting options vetur uses for each block of code in VUE. Vetur uses the prettyHTML plugin to format the


Opinionated general formatter for your Angular, Vue, Svelte or pure HTML5 templates.


Prettyhtml is a general-purpose formatting plugin for vue and others, also used by Vetur. In comparison, I found that the plugin formats most exactly as esLint would format several times, not as prettier and JS-beutify-html (used by default before Vetur) format themselves.

So we leave the formatting of


With this configuration, vscode can format eslint rules that compare blocks of code in a vue file. The comparison actually means that prettyhtml differs slightly from eslint-plugin-vue rules. According to eslint, Tags with multiple attributes are bound to wrap, whereas prettyHTML uses the length of the tag to wrap, which is more elegant.


Format the configuration for the project

If the team needs to force each developer to use the plug-in’s and corresponding configuration, it can create a workspace configuration file settings.json in the project folder. Just copy the settings.json content from the user’s Settings to the workspace and save it. Vscode will automatically generate a.vscode folder to put in the root directory.


Next, submit the.vscode folder to the remote repository, and then each developer involved in the project will pull down the corresponding project configuration file along with the project and configure it uniformly.


Note: The Workspace configuration folder only works if it is located at the root of the open workspace.





Note the name of the workspace at the top of the image. The first image opens the workspace in the yp-web-console folder. The.vscode folder is not in this directory, so the workspace configuration will not take effect. The second image opens the VUECLI3 folder with the.vscode folder at the root. The workspace configuration takes effect.

Third, version management tool submission verification

The previous two parts explained how team members can format code according to a uniform specification when they write code, but this part of the commit verification is to prevent members from bypassing the specification limits in the writing process and directly committing illegal code to the code base to pollute.

Using git as an example, git provides hooks at various points in the code submission process. In this case, hooks are used to verify that failed code is intercepted and the submission process is terminated. So the pre-commit hook is used. (There is also a common hook called commit-msg, which is used to check whether the commit follows the specified template. If you are interested, you can Google it.)

To operate on git hooks, you need to write.git/hooks files in your project using low-level commands, but you can use an existing tool, Husky, to keep the implementation costs down. Husky is an NPM installation that integrates low-level commands to call various Git hooks. It is a fool’s game, just follow the documentation.



This allows esLint to validate code in the pre-commit hook at commit time, and if there is any code that does not conform to the rules, the commit will be terminated immediately to avoid code contamination. However, there are two problems after adding verification:

1. The first point is that ESLint will verify all files in the entire project at commit time. If the project is very large, the verification will become very long, slowing down the commit time;

2. The second point is that after validation, ESLint will automatically format some code that does not conform to the rules, but you will need to submit any changes to the auto-formatted code again.

Through Google, lint-staged plug-in was found to solve problems by changing the validation strategy from validating the entire project code to validating only the modified or newly added code or files, which greatly reduced the validation range and thus improved the efficiency of validation. At the same time, it can merge multiple commands in sequence, and the issues mentioned above that need to be committed again can be added to the changes that need to be committed through Git add. Lint-staged installation can also be done using NPM packages and package.json will look something like this:



This will allow for quick validation purposes. Let’s see what happens with pre-commit.


Briefly tested the validation speed of submission before and after lint-staged changes. The same code changes were submitted before and after lint-staged changes (left) and felt somewhat effective.



At this point, the whole specification process has been basically established, and project members can clear up the code conflicts and ugly code, and happily pair programming.


As a follow-up, you can actually publish the entire specification as a base scaffolding on the NPX, so that each new project can use the specification and develop on top of it, rather than having to redo each project. I will continue to work on this one when I have time and then publish it.


Finally, I want to say that tools are dead and people are alive. In the final analysis, these normative tools are only against gentlemen rather than villains. As long as you understand the principle, there are various ways to bypass the normative restrictions. And the code to achieve team truly specification, I don’t feel I can only rely on these tools do limit, the most core is to emphasize the importance of the specification in the process of team building, team members are determined to standardise the idea rather than rules resentment multifarious trivial, so tools to play its proper role.


Reference links:

Husky, lint – staged zhuanlan.zhihu.com/p/35913229

Eslint vscode plugin stackoverflow.com/questions/5…