ESLint: catching JavaScript mistakes before the code ever runs

Some mistakes only appear at run time, and sometimes only on a visitor's page: a misspelled variable, a promise nobody awaited, a questionable comparison. The code works right up to the day it does not.

ESLint reads the file without launching it and reports those flaws while you write.

Definition

ESLint is a static analyzer for JavaScript: it turns code into a tree, applies a set of rules and reports every deviation. Rules are configurable one by one, which lets each team define what it treats as a fault.

// eslint.config.js
import js from '@eslint/js';

export default [
  js.configs.recommended,
  {
    rules: {
      'no-unused-vars': 'warn',
      'no-console': 'off',
      eqeqeq: 'error',
    },
  },
];

Each rule takes one of three values, off, warn or error. Only the last one makes the command fail, which lets a team block a merge on an error while tolerating warnings.

What it actually catches

• Forgotten variables: declared and never used, or used without ever being declared.
• Dropped promises: a missing await in front of an asynchronous call, reported by the TypeScript plugin, which reads types to know what returns a promise.
• Unreachable code: lines sitting after a return.
• Risky comparisons: Loose equality (==) where Strict equality (===) belongs.
• Library-specific rules: through plugins, such as the constraints around React hooks.

Adopting it without suffering

The npx eslint . command analyzes the project, and the --fix option repairs on its own everything that can be repaired unambiguously. Your editor extension shows the same reports live, which remains the most useful loop.

On an existing project, switching on a complete rule set at once produces thousands of reports nobody will read. Better to start from the recommended configuration, get it passing, then add rules one at a time and fix as you go.

Frequently asked questions

A // eslint-disable-next-line rule-name comment turns the rule off for the following line. Always name the rule concerned, and add the reason: an unexplained exception becomes a mystery six months later.

No, the two look at different things. ESLint checks the shape of the code without ever running it, while a Unit test checks the result obtained for given inputs. The first catches the typo, the second catches the wrong calculation.

Yes, that is when it costs the least: the recommended configuration is enough, and the project grows alongside it. The basic rules also teach a lot about the language itself, since each report points at a real trap. Our JavaScript course revisits those traps, from floating point numbers to misleading comparisons.