Best Practices of Code Standardization Engineering for Small and Medium-sized Front-end Teams-ESLint

Preface

There are a thousand Hamlets in a thousand people's eyes.

For a thousand programmers, there are a thousand coding styles. In front-end development, there are several code style differences that are still being debated:

• Single quote or double quote?
• Do I need a semicolon at the end of the code line?
• Two spaces or four spaces?
• ...

These differences in code styles are often complained to each other in collaborative development, or even unbearable.

In addition, due to the flexibility of JavaScript, a piece of code can often be written in multiple ways, which can also lead to differences in collaboration. In addition, there are some writing methods that may lead to bugs that are not easy to find, or the performance of these writing methods is not good, and should be avoided during development.

In order to solve this kind of static code problem, each team needs a unified JavaScript code specification, and team members all abide by this code specification to write code. Of course, relying on people to guarantee code specifications is unreliable and requires corresponding tools to ensure that ESLint is this tool.

Some readers may say: Prettier can also ensure the code style is consistent. Yes, Prettier can indeed format the code uniformly according to the set rules, and there will be corresponding introductions in the following articles. But one thing to be clear is that Prettier will only format the code. Some hidden code quality problems cannot be found by Prettier, while ESLint can.

About ESLint

Regarding ESLint , its Slogan is Find and fix problems in your JavaScript code. As mentioned above, it can find and fix problems in your JavaScript code. Take a look at the official website describing the three features of ESLint:

• Find Problems . ESLint can quickly find problems in the code through static code analysis. ESLint can be run in most text editors, and ESLint can also be connected to the workflow
• Fix Automatically . Many problems found by ESLint can be automatically fixed
• Customize . You can customize ESLint inspection rules

Based on the above description, we can use ESLint as follows in front-end engineering:

1. Customize a set of unified ESLint code rules based on the industry’s existing ESLint specifications and team code habits
2. Encapsulate unified code rules into ESLint rule package access
3. Integrate ESLint into scaffolding, editors, and R&D workflows

Get started quickly

first briefly introduce how to use ESLint, if you already know something about it, you can skip this section directly.

Create a new package.json (you can execute npm init -y in an empty directory), create a new index.js :

// index.js
const name = 'axuebin'

Install eslint :

npm install eslint --save-dev

Then execute ./node_modules/.bin/eslint --init or npx eslint --init generate an ESLint configuration file .eslintc.js :

module.exports = {
  env: {
    es2021: true,
  },
  extends: 'eslint:recommended',
  parserOptions: {
    ecmaVersion: 12,
  },
  rules: {},
};

After the configuration file is generated, you can execute the ./node_modules/.bin/eslint index.js or npx eslint index.js command to check the file. The results are as follows:

index.js code hit no-unused-vars this rule, by default, this rule will be reported error , that is ESLint unused variables do not allow the code appears . This is a good habit and is conducive to code maintenance.

Simple configuration

Let's try to configure ESLint's inspection rules. Take the semicolon and quotation marks as an example. Now you, as the designator of the team code specification, hope that the codes developed by team members are single quotation marks and with semicolons .

Open the .eslintrc.js configuration file and add related configuration items rules

module.exports = {
  env: {
    es2021: true,
  },
  extends: 'eslint:recommended',
  parserOptions: {
    ecmaVersion: 12,
  },
  rules: {
    semi: ['error', 'always'],
    quotes: ['error', 'single'],
  },
};

Then we change the code in index.js

// index.js
const name = "axuebin"

After executing the eslint command:

You can see the check results are as follows:

• [no-unused-vars] ' is assigned a value but never used. The name variable is defined but not used.
• [quotes] Strings must use singlequote. The string must use single quotes.
• [semi] Missing semicolon. The semicolon is missing.

Modify the code honestly according to the specification, use single quotes and add semicolons. Of course, if you want double quotes and no semicolons, you can modify the corresponding configuration.

How to configure specific rules can be viewed: https://eslint.org/docs/rules

Auto repair

Executing eslint xxx --fix can automatically fix some problems in the code and expose the problems that cannot be automatically fixed. For example, the quotation marks and semicolons mentioned above can be --fix , while the no-unused-vars variables of 06076b6268b877 can not be automatically repaired by ESLint.

Use configuration package

In init , we see that this line of code is included:

module.exports = {
  extends: "eslint:recommended"
}

This line of code means to use ESLint's recommended configuration. extends: 'xxx' is that inherits , the current configuration inherits xxx , and expands on this basis.

Thus, we can also use any packaged configuration, it is possible of NPM or on GitHub search eslint-config keyword obtaining herein packaged configuration will be such as "Set Configuration." The more common configuration packages are as follows:

• eslint-config-airbnb : configuration set provided by Airbnb
• eslint-config-prettier : Using this configuration set will close some rules that may conflict with Prettier
• eslint-config-react : The configuration set used by create react app
• eslint-config-vue : configuration set used by vuejs
• ...

Best Practices

After a brief understanding of ESLint, more details and principles of ESLint use will not be expanded in this article, and interested friends can learn more about it on the official website. This article focuses on lies how landing ESLint team engineered system , to mention a few best practices here.

Abstract configuration set

For independent developers and small teams with simple business scenarios, it is very efficient to use a ready-made and complete third-party configuration set, which can access ESLint code inspection at a lower cost.

However, for large and medium-sized teams, during the actual implementation of the code specification, we will find that it is impossible to have a three-party configuration package that fully conforms to the team’s style. We will still use the extends three-party configuration set, and then manually rules some custom rules to the 06076b6268ba6b configuration. After a long time, it is possible that the rules in the A application and the B application will be different, and it will be difficult to achieve a unified goal.

At this time, a centralized way is needed to manage the configuration package: according to the team’s code style (or based on the existing three-party configuration set) and released a configuration set. The team uses this package uniformly to achieve centralized management and Update .

In addition, from a technical perspective, the current scenario faced by a front-end team may be more complicated. such as:

• Technical selection is inconsistent : The framework uses React for PC and Vue for H5; whether to use TypeScript
• cross-terminal scenes : Web terminal, small program terminal, and Node
• ...

The above problems exist in real development, so when the code standard engineering scheme is implemented, a single function configuration set is not enough. At this time, it is also necessary to consider how this configuration set is abstracted.

In order to solve the above problems, here is a solution idea:

In terms of specific disassembly, there is a basic rule set similar to eslint-config-standard (including code style, variable correlation, ES6 syntax, etc.), and some plug-ins (Vue/React) of the community are integrated on this basis, encapsulated It is released into a unified NPM Package, and the corresponding configuration set is extended through different paths according to the current application type during consumption.

Here is a demo, interested friends can take a look: eslint-config-axuebin

Development plug-in

ESLint provides a wealth of configurations for developers to choose from, but these general rules are not enough under complex business scenarios and specific technology stacks. ESLint is extensible in the form of plug-ins. Developers can customize any inspection rules. For example, eslint-plugin-vue / eslint-plugin-react is an extension plug-in used in the Vue / React framework. The official website also provides related documents. guides developers to develop a plug-in.

Generally speaking, we don't need to develop plugins, but we need to understand at least that there is such a thing. When doing some team code quality checks, we may have some special business logic. At this time, the ESLint plug-in can help us do some things.

I won't expand here, mainly the usage of some AST, you can get started according to the official document, or you can refer to some existing plug-in writing methods.

Scaffolding / CLI tools

When we have the team's unified ESLint configuration set and plugins, we will integrate them into the scaffolding to facilitate new project integration and out-of-the-box use. But for some old projects, if you need to modify manually, there will be some troubles. At this time, you can use CLI to complete the one-click upgrade.

This article combines the above Demo eslint-config-axuebin to design a simple CLI Demo. Since the current configuration is relatively simple, CLI only needs to do a few simple things:

• Ask the user the type of the current project (Is it JavaScript or TypeScript, React or Vue)
• .eslintrc.js file according to the project type
• Install the required dependencies according to the project type (for example, vue requires eslint-plugin-vue)
• In package.json of scripts writing "lint": "eslint src test --fix"

The core code is as follows:

const path = require('path');
const fs = require('fs');
const chalk = require('chalk');
const spawn = require('cross-spawn');

const { askForLanguage, askForFrame } = require('./ask');
const { eslintrcConfig, needDeps } = require('./config');

module.exports = async () => {
  const language = await askForLanguage();
  const frame = await askForFrame();

  let type = language;
  if (frame) {
    type += `/${frame}`;
  }

  fs.writeFileSync(
    path.join(process.cwd(), '.eslintrc.js'),
    `// Documentation\n// https://github.com/axuebin/eslint-config-axuebin\nmodule.exports = ${JSON.stringify(
      eslintrcConfig(type),
      null,
      2
    )}`
  );

  const deps = needDeps.javascript;
  if (language === 'typescript') {
    deps.concat(needDeps.typescript);
  }
  if (frame) {
    deps.concat(needDeps[frame]);
  }

  spawn.sync('npm', ['install', ...deps, '--save'], { stdio: 'inherit' });
};

For the executable CLI Demo code, see: axb-lint , execute it in the project directory: axblint eslint , as shown in the figure:

automation

After configuring ESLint, we need to make developers aware of ESLint's constraints. Developers can run the eslint command to run the code inspection, which is not efficient enough, so we need some automated means to do this. Of course, during development, the editor also provides corresponding functions to check the file currently being edited according to the ESLint configuration file under the current workspace. This is not the focus of our concern.

Generally, we will perform ESLint checks in the following ways:

• when developing : Depends on the ability of the editor
• Manual operation : Manually execute the eslint command in the terminal
• pre-commit : automatically execute the eslint command before submitting git
• ci : Relying on the continuous integration of git, you can upload the check result output file to the server

Let me mention the pre-commit scheme. Before every local development and submit code, ESLint check is done to ensure that the code in the cloud is unified and standardized.

This method is very simple, only need to rely on husky and lint-staged project. After installing the dependencies, add the following configuration to the package.json file:

{
  "lint-staged": {
    "*.{js,jsx,ts,tsx}": "eslint --cache --fix"
  },
  "husky": {
    "hooks": {
      "pre-commit": "lint-staged"
    }
  }
}

The effect is shown in the figure:

If the code runs ESLint and throws an Error error, the commit process will be interrupted:

This ensures that the code submitted to the GitHub repository is uniform and standardized. (Of course, if you think that these configuration files are deleted, there is no way)

to sum up

This article introduces some best practice ideas of ESLint in small and medium front-end teams. You can expand on this basis to develop a complete ESLint workflow and implement it in your team.

This article is one of a series of articles on front-end code specifications. There will be articles on StyleLint/CommitLint/Prettier, etc., and a complete article on the front-end code specification engineering practice , so stay tuned ( is also possible Just dove ).

---

For more original articles, please pay attention to the public a programmer who plays with the camera ", or add me to WeChat xb9207 to communicate