Gera Tools

ESLint Rule Categories Reference

ESLint rule categories — possible-errors, best-practices, ES6 — with rule counts.

Searchable ESLint core rule reference organized by category — Possible Problems, Suggestions, Layout & Formatting — with the auto-fixable flag and whether each rule is in the recommended preset. It runs free in your browser on Gera Tools, with nothing uploaded.

Last updated Source: Gera Tools

What are the main ESLint rule categories?

Since ESLint 8 the core rules are grouped into three types: Possible Problems, which catch likely bugs; Suggestions, which improve code without flagging clear errors; and Layout & Formatting, which concern whitespace and style. Older docs used Possible Errors, Best Practices, Variables, Stylistic and ES6.

ESLint rules grouped by category

ESLint ships dozens of built-in core rules. Since ESLint 8 they are organized into three categories by intent, and each rule carries two important flags: whether eslint --fix can auto-correct it, and whether the eslint:recommended preset enables it. This searchable reference lists representative core rules per category so you can find what a rule does and how to wire it up.

The three categories explained

Possible Problems

Rules that catch code that is very likely to be a bug or to cause unexpected behaviour at runtime. These are the highest-confidence rules — violations are almost always wrong:

  • no-undef — catches references to variables that are never declared
  • no-unreachable — catches code after return, throw, or continue
  • no-unused-vars — catches variables declared but never read
  • no-const-assign — catches reassignment of const bindings
  • no-duplicate-case — catches duplicate case labels in switch

Most Possible Problems rules are not auto-fixable because the safe correction is ambiguous — removing the unused variable versus using it are both valid fixes.

Suggestions

Rules that improve code style and correctness without flagging outright errors. Violations indicate a pattern that could cause confusion or has a cleaner equivalent:

  • prefer-const — suggests const when a let binding is never reassigned
  • eqeqeq — requires === and !== instead of == and !=
  • no-var — disallows var in favour of let/const
  • curly — requires braces around all control-flow bodies
  • arrow-body-style — enforces concise arrow functions where possible

Many Suggestion rules are auto-fixable.

Layout and Formatting

Rules controlling whitespace, indentation, and brace style. These are deprecated in the core — ESLint recommends moving formatting to Prettier or the @stylistic/eslint-plugin instead and focusing ESLint on correctness. They remain in core for backwards compatibility but will not receive new features.

How to enable a rule

// eslint.config.js (flat config)
export default [
  {
    rules: {
      "no-unused-vars": "error",
      "eqeqeq": ["error", "always"],
      "prefer-const": "warn"
    }
  }
];

Severity values: "off" or 0, "warn" or 1, "error" or 2. Only "error" causes eslint to exit with a non-zero code and fail CI. Use "warn" for rules you want to surface without blocking builds while the team migrates.

  • Fixable: when running eslint --fix, any rule flagged as fixable will have its violations corrected automatically. Layout rules are usually fixable; Possible Problems rules usually are not.
  • Recommended: the eslint:recommended preset (in flat config, js.configs.recommended) enables a curated set of high-confidence core rules. These are the rules marked as recommended in this reference. It is a safe, minimal baseline — extend it with your own rules rather than replacing it.

Tips

  • Start from eslint:recommended, then add rules as your team agrees on them — avoid enabling everything at once.
  • Prefer --fix for the fixable Suggestion and Layout rules to save manual work.
  • Move pure formatting to Prettier; keep ESLint focused on correctness.
  • A rule’s severity can be off, warn or error; only error fails CI.
  • Use "warn" for new rules being introduced to a legacy codebase to surface violations without immediately blocking deployments.