ESLint Explained: Catching Bugs Before They Run

Introduction

Some bugs only appear when code runs — and the worst ones appear in production. ESLint catches a whole class of them earlier, by reading your code without running it (static analysis) and flagging patterns that are known to be wrong, risky, or inconsistent. It is the standard linter for JavaScript and TypeScript, and it belongs in essentially every project.

Rules: small checks, big catches

ESLint works through rules, each checking one thing:

// no-unused-vars: this variable is never used — probably a mistake
const userName = "Sara";
console.log("Hello");
// no-undef: this variable was never declared — a typo, or a missing import
console.log(userNmae);

A rule is either off, a warning, or an error. Warnings show up in your editor as you type; errors can block a commit or a pull request (paired with the GitHub Actions automation from the last batch, so broken code never merges). Rules also enforce team conventions — consistent use of const over let, no floating promises — so code reviews stop arguing about style and focus on logic.

Configuration: shareable, not personal

Nobody writes hundreds of rules by hand. Projects extend shareable configs — eslint:recommended for the sensible defaults, plus framework configs for React, Vue, or TypeScript — and override only the handful of rules they disagree with:

// eslint.config.js
export default [
  {
    rules: {
      "no-console": "warn",
      "no-unused-vars": "error",
    },
  },
];

Because the config lives in the repository, every developer and every CI run checks the same rules. A new team member gets the same guardrails on day one, with no setup and no arguments about whose editor settings are right.

The honest trade

ESLint only catches what its rules describe — it won't find logic errors, and an over-strict config (hundreds of pedantic rules) makes developers fight the tool instead of using it. Start with the recommended set, add rules when a real bug motivates them, and remember that a linter is a safety net, not a substitute for tests (Jest and Cypress from the last batch) or review.

Takeaway

Static analysis finds bugs before code runs, rules turn team conventions into automatic checks, and a shared config gives every developer the same guardrails. ESLint is the cheapest bug-catching tool in a JavaScript project — it costs nothing to run and catches mistakes every day.

Originally published at https://practicaldevblog.blogspot.com/2026/10/eslint-explained-catching-bugs-before.html