跪拜 Guibai
← Back to the summary

ESLint's First Five Rules: A Beginner's Confrontation with the Code Security Guard

👍 My Code Got Caught by ESLint: Single Quotes, var, No Semicolons—All Called Out on the Spot

This article has no proper opening. Today was my first formal encounter with ESLint, and as soon as I submitted my code, I was caught red-handed by an "invisible security guard." It doesn't speak, only reports errors, and every line is so precise it makes your scalp tingle. Below is the complete record of my confrontation with this "code security guard."

First, Meet This "Security Guard"

Let's start with the conclusion: ESLint is a crucial guarantee for code project quality. It forces a team to write code in a consistent style and strictly checks for potential bugs in the code.

Sounds like a "code style checking tool"?
No, it's more like a "disciplinary committee member with late-stage OCD and a bloodhound's sense of smell."

It doesn't run your code, but it will sift your code through a set of rules—any line that doesn't conform gets called out on the spot.

First Confrontation: no-var, Banning var

My code (almost wrote it like this):

var name = "qxh";   // ❌ If written like this, you get called out immediately

ESLint rule (eslint.config.mjs):

rules: {
    "no-var": 2,      // Cannot use var! 2 = error, reports an error directly
    ...
}

What do the numbers in the rules mean?

Number Level Meaning
0 off Turned off, ignored
1 warn Warning, does not block
2 error Error, must be fixed

"no-var": 2 means: whoever writes var gets a compilation error.

The correct way:

let name = "qxh";   // ✅ let conforms to the standard

Why ban var? It's an old story: var has no block-level scope, can attach to the window object and pollute the global scope, and causes all sorts of weird bugs due to hoisting. Banning it in team code eliminates a whole category of "paranormal events" at the source.

Second Confrontation: quotes and semi, Double Quotes + Semicolons

rules: {
    "quotes": ["error", "double"],  // Must use double quotes
    "semi": ["error", "always"],    // Must add semicolons
    ...
}

Scene of being called out:

let name = 'qxh'    // ❌ Single quotes + no semicolon, a double whammy
hello()             // ❌ No semicolon

Compliant posture:

let name = "qxh";   // ✅ Double quotes
hello();            // ✅ Has a semicolon

Why be so strict? Because in team collaboration, the most energy-draining thing is often not algorithmic challenges, but "why doesn't the code you wrote look like it was written by the same person as mine"—unifying quotes and semicolons makes the code look like it came from a single hand, making reviews psychologically burden-free.

Third Confrontation: indent, Indentation Must Be 2 Spaces

rules: {
    "indent": ["error", 2]   // Indentation must be 2 spaces
}

Scene of being called out:

function hello() {
    console.log(name + "hello");  // ❌ 4-space indent? Error!
}

Compliant posture:

function hello() {
  console.log(name + "hello");  // ✅ 2 spaces
}

Is there a difference between writing 4 spaces and 2 spaces? Not to the machine, but to the team—if a dozen people indent according to their own preferences, the code becomes a "visual disaster zone." Unified indentation is the baseline for maintaining code readability.

Fourth Confrontation: no-console, Warning but Doesn't Block

rules: {
    "no-console": 1   // 1 = warn, warning
}

Why manage console.log too?

So ESLint's attitude is: warning (1), not an error (2)—you can log during development, but remember to clean them up before going live.

This is like a "verbal warning" in school: it doesn't go on your record, but you should be aware of it.

Complete Configuration Overview

Summarizing all the rules we were called out on (eslint.config.mjs):

import js from "@eslint/js";
import globals from "globals";
import tseslint from "typescript-eslint";
import { defineConfig } from "eslint/config";

export default defineConfig([
  {
    files: ["**/*.{js,mjs,cjs,ts,mts,cts}"],
    plugins: { js },
    extends: ["js/recommended"],           // JS official recommended rule set
    languageOptions: { globals: globals.node },  // Node environment global variables
    rules: {
      "no-var": 2,                    // Ban var (error)
      "no-console": 1,                // Ban console (warn)
      "quotes": ["error", "double"],  // Double quotes
      "semi": ["error", "always"],    // Must have semicolons
      "indent": ["error", 2]          // 2-space indentation
    }
  },
  tseslint.configs.recommended,       // TS official recommended rule set
]);

The four layers of configuration:

Part Role
extends: ["js/recommended"] Introduces JS official recommended rules (free ride)
tseslint.configs.recommended Introduces TS official recommended rules
languageOptions.globals Declares the environment (Node's global variables aren't falsely reported)
rules Custom rules, overriding team conventions

Confrontation Over: Why Must a Team Use ESLint?

After being "caught" all afternoon, my real feelings:

  1. Eliminates potential bugs: Rules like no-var directly seal off a category of hidden dangers.
  2. Unifies code style: No matter who wrote it, it looks like it was written by one person.
  3. Makes reviews easier: The reviewer doesn't have to agonize over "why did you use single quotes," and can just focus on logic.
  4. Helps newcomers get up to speed quickly: Not conforming? An error is reported upon saving, and they learn the standard on the spot.

ESLint doesn't restrict you; it protects the entire team's code from being drowned in "stylistic chaos." It's like a physical exam report—annoying to look at, but it can save your life.

Finally, the Key Points

If an interviewer asks "What does ESLint do, and how are its rule levels divided?", remember three sentences:

All code examples in this article are from classroom learning materials and are genuinely runnable.