Linting with ESLint

What a linter does

A linter is an automatic checker that reads your code and reports likely mistakes before you run the code. ESLint is the most common linter for JavaScript. It can catch a misspelled variable name, a comparison your team has decided to avoid, unreachable code after a return, or a value that was created and then forgotten.

The important word is reads. ESLint usually does not click your page, call your functions, or prove every possible behavior. It parses the file, applies configured rules, and gives you a message with a rule id, a line and column, and a severity: warning or error.

Earlier lessons gave you tools, strict mode, semicolons, and coding style. Linting combines those habits into feedback you see while you type. npm and package.json get their own lesson later, so for now just recognize commands like npm init @eslint/config@latest and npx eslint as ways to set up and run the checker.

1const total = 1 + 2;Run2console.log(totla);

ESLint output is meant to be read like a checklist, not like a scary stack trace. Each message names the rule that spoke. Toggle rules in the playground and notice that rules are independent: the output is the union of the enabled rule results for the selected snippet.

1if (score == "10") {2  console.log("match");3}

A useful lint message usually answers four questions: what rule fired, where is the code, how serious is it, and can ESLint safely fix it? Rule ids are searchable, so no-undef means “a name was used but never declared,” and prefer-const means “this let never changes.”

A rule is one house rule for code. A config is the rulebook ESLint reads before checking files. ESLint 9 uses a flat config file named eslint.config.js by default. A common starting point imports recommended JavaScript rules, then adds project-specific choices.

1import js from "@eslint/js";2 3export default [4  js.configs.recommended,5  {6    languageOptions: {7      globals: {8        document: "readonly",9        console: "readonly"10      }11    },12    rules: {13      eqeqeq: "error",14      "no-unused-vars": "warn"15    }16  }17];

Severities can be written as strings or numbers: off is 0, warn is 1, and error is 2. Warnings are yellow sticky notes: useful, but not always build-breaking. Errors are stop signs. Use errors for bugs or project rules that should fail CI.

Some lint messages are safe to fix mechanically. ESLint calls those fixable. For example, if a variable is declared with let and never reassigned, prefer-const can rewrite it to const without changing the program’s output. Other rules, such as no-undef, usually need a human: ESLint cannot know whether you meant total, totla, or a new variable.

1let limit = 3;Run2console.log(limit);

In a terminal, npx eslint . reports problems and npx eslint . --fix asks ESLint to apply safe fixes. The npm lesson later will explain exactly what npx and project scripts do. For now, read the command as “run ESLint on this project.”

1npm init @eslint/config@latest2npx eslint .3npx eslint . --fix

ESLint is most helpful when your editor shows it before you switch to the terminal. In VS Code, install the ESLint extension. It reads the project’s config, underlines problems, offers quick fixes, and can apply safe fixes when you save. Recent VS Code settings use "explicit" for save actions; older examples accepted true.

1{2  "editor.codeActionsOnSave": {3    "source.fixAll.eslint": "explicit"4  }5}

1let limit = 3;2console.log(limit);

1{2  "editor.codeActionsOnSave": {3    "source.fixAll.eslint": "explicit"4  }5}

Editor integration does not replace learning the rule. When a squiggle appears, read the message, look at the line, and decide: accept the quick fix, change the code yourself, or make a deliberate exception. That habit turns linting into coaching instead of noise.

The previous lesson introduced Prettier formatting. A formatter is a copy editor for layout. It chooses indentation, line wrapping, and other style details so humans stop arguing over them. A linter is more like a proofreader looking for suspicious meaning: unused names, unknown variables, unreachable code, and rules your team chose.

Where you’ll use linting

In a real project, linting appears in three places. First, the editor shows squiggles while you type. Second, a terminal command checks the whole project before you share work. Third, a team may run the same command in CI, which is an automated check before code is merged.

Imagine building a small shopping-cart page. A linter cannot tell you whether the checkout design is good. It can catch that cartTotal was misspelled as cartTtoal, that code after return will never run, or that two object keys use the same name and one silently overwrites the other.

1const limit = 3;2console.log(limit);

Common misconceptions

Try each question before opening explanations. Several choices are plausible, because real linting decisions are about tradeoffs.

Key takeaways

• A linter reads code before it runs and reports rule violations.
• ESLint messages include a rule id, severity, line, column, message, and sometimes a safe fix.
• Configs are rulebooks. In ESLint 9, eslint.config.js is the default flat config file.
• Use error for stop signs and warn for guidance.
• Fix on save and editor squiggles make linting part of the writing loop.
• Formatters handle layout; linters handle rule-based code quality.

Up next: Thinking like a developer.