Shulou(Shulou.com)06/02 Report--

This article mainly introduces "how to achieve the git code specification". In the daily operation, I believe that many people have doubts about how to achieve the git code specification. The editor consulted all kinds of materials and sorted out simple and easy-to-use operation methods. I hope it will be helpful to answer the doubts about "how to achieve the git code specification". Next, please follow the editor to study!

ESLint and constraint

Unified coding standards can not only greatly improve the readability of the code, but also improve the quality of the code. When we design a set of rules about coding specifications, we need tools to assist detection, which is called ESLint.

$npm install eslint-save-dev

The rule set needs to be configured centrally. ESLint reads the configuration file .eslintrc by default to resolve it, while the rule set is configured in rules:

{"rules": {"semi": ["error", "always"], "quotes": ["error", "double"]}}

What we need to do is to set our code specification, that is, the rules item.

Don't repeat the wheel.

Do we need to start all over again and design a set of coding specifications that belong to our team?

There is no need to start all over again. It takes a lot of manpower and it is difficult to cover all the rules.

Many good teams have set particularly good coding specifications based on best practices, such as airbnb, which sets a set of specifications that are particularly constrained. There are also some very simple but very practical specifications, such as eslint:recommended.

Airbnb javascript style [2]

We just need to use the extend configuration item to inherit some good open source code specifications and use rules to supplement some of our team's rules.

{"extend": ["airbnb-base"], "rules": {"semi": ["error", "never"]}}

Development environment, production environment and warnings

What is important to the development environment for development?

It's a development experience.

A good coding specification can bring the comfort of liberating obsessive-compulsive disorder, but an overly strict code style can sometimes be irritating. Let me give you two small examples of scenarios that may have occurred when you were writing code:

Disable console.log to avoid exporting excess stuff in a production environment. However, debugging is often needed in the test environment, but if only set as a warning, the warning will be ignored and meaningless.

Especially when the rule no-unused-vars is set. If it is only for debugging at development time, it is not easy to debug because it cannot pass the ESlint rule verification.

This is a trade-off between constraints and freedom, and ESLint naturally sacrifices some development convenience when providing strong constraints. The Doctrine of the mean, Confucianism pays attention to the Doctrine of the mean, at this time, we can choose a moderate plan under the balance:

Set all the rule checks of ESLint that affect debugging to Warn, and if you ask again, aren't warnings often ignored? This is the case, so you need to set the environment variable CI=true in CI so that it cannot be delivered even if there is a warning in CI.

For example, most of the rules in create-react-app are set to Warn

However, if you use webpack and combine eslint-loader, the solution is even simpler: use emitWarning: true, and treat all Error as Warn in the test environment, thus avoiding changing the ESLint rules. The configuration of webpack is as follows:

{test: /\. (js | mjs | jsx | ts | tsx) $/, enforce: 'pre', use: [{options: {cache: true, emitWarning: true,}, loader: require.resolve (' eslint-loader'),},]}

So there are two ways to weigh development experience against programming specifications:

Set the rule of ESLint to Warn and configure the environment variable CI=true in continuous integration.

Combine webpack with eslint-loader to configure emitWarning according to the environment variables of the current environment.

Layer 1 constraint: IDE

When the code does not conform to the specification of the first time, we have to perceive it, timely feedback, quick correction, than finally accumulated a lot of errors is much more efficient.

Here, take VS Code as an example. You only need to install a plug-in: eslint, and you can do the smart prompt. Let's see the effect:

In addition, with eslint-loader, you can also use the browser to provide real-time prompts:

Layer 2 constraint: Git Hooks

One of the coding specifications in teamwork is that although you may be uncomfortable, you can't make others uncomfortable because of your own code.

Git itself contains a number of hooks that triggers execution before and after git events such as commit,push. Combining with pre-commit hook can help validate Lint, and submission is not allowed if it is not through the code specification.

Husky [3] is a tool that makes git hooks easier, and you only need to configure a few lines of package.json to get started happily.

(1) what is the principle of husky?

/ / package.json {"scripts": {"lint": "eslint.-- cache"}, "husky": {"hooks": {"pre-commit": "npm lint",}

Or call verification rules in conjunction with lint-staged [4]

{"husky": {"hooks": {"pre-commit": "lint-staged"}}, "lint-staged": {"* .js | {lib,setup,bin,hot,tooling,schemas} / * * / * js | test/*.js | {test,examples} / * * / webpack.config.js}": ["eslint-- cache"], "*. {ts,json,yml,yaml" Md} | examples/*.md ": [" prettier-- check "]," * .md | {.GitHub, benchmark,bin,examples,hot,lib,schemas,setup,tooling} / * * /. {md,yml,yaml,js,json} ": [" cspell "]}}

However, front-end users all know that client-side verification is unreliable and can be bypassed by a single command.

$git commit-n

Layer 3 constraint: CI

Git hooks can be bypassed, but CI (continuous Integration) can never be bypassed because it is validated on the server side. Using gitlab CI for continuous integration, the configuration file. gitlab-ci.yaml is as follows:

Lint: stage: lint only:-/ ^ feature\ /. * $/ script:-npm lint at this point, the study on "how to implement the git code specification" is over. I hope I can solve your doubts. The collocation of theory and practice can better help you learn, go and try it! If you want to continue to learn more related knowledge, please continue to follow the website, the editor will continue to work hard to bring you more practical articles!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.