ESLint полезен не потому, что “держит код красивым”, а потому, что ловит реальные ошибки еще до запуска приложения: забытые зависимости, мертвый код, опасные сравнения, неправильные импорты и нарушения командных правил.

Сегодня его лучше воспринимать как слой проверки качества, а не как замену форматтеру. За форматирование обычно отвечает Prettier, а ESLint должен концентрироваться на логике, ошибках и архитектурных ограничениях.

Обновлено 17 марта 2026: статья переписана под современный flat config и локальную установку ESLint вместо устаревшего .eslintrc.

Что именно дает ESLint

ESLint помогает в трех вещах:

  • ловит потенциальные ошибки до runtime;
  • фиксирует договоренности команды в одном месте;
  • делает review короче, потому что повторяющиеся замечания закрывает автоматическая проверка.

Это особенно полезно в JavaScript и React-коде, где часть проблем видна только через анализ AST, а не на уровне типов.

Установка в проект

Устанавливай ESLint локально, а не глобально. Конфигурация должна жить вместе с репозиторием и версионироваться вместе с кодом.

npm install --save-dev eslint @eslint/js globals

Если нужен React-проект, сразу добавь соответствующие плагины:

npm install --save-dev eslint-plugin-react eslint-plugin-react-hooks

Глобальная установка почти всегда мешает: локально у проекта одна версия ESLint, а у тебя в системе может стоять другая.

Минимальный eslint.config.js

Начиная с современных версий ESLint, базовой конфигурацией считается flat config. Минимальный рабочий файл для обычного JavaScript-проекта может выглядеть так:

// eslint.config.js
const js = require("@eslint/js");
const globals = require("globals");

module.exports = [
  js.configs.recommended,
  {
    files: ["**/*.{js,mjs,cjs}"],
    languageOptions: {
      ecmaVersion: "latest",
      sourceType: "module",
      globals: {
        ...globals.browser,
        ...globals.node,
      },
    },
    rules: {
      "no-console": "warn",
      "no-unused-vars": ["error", { argsIgnorePattern: "^_" }],
    },
  },
];

Здесь важно не количество правил, а их качество. Начни с recommended, а дальше добавляй только те ограничения, которые реально помогают команде.

React и JSX

Для React лучше явно подключить react и react-hooks, потому что именно они закрывают частые ошибки вокруг JSX и хуков.

// eslint.config.js
const js = require("@eslint/js");
const globals = require("globals");
const reactPlugin = require("eslint-plugin-react");
const reactHooksPlugin = require("eslint-plugin-react-hooks");

module.exports = [
  js.configs.recommended,
  {
    files: ["**/*.{js,jsx}"],
    languageOptions: {
      ecmaVersion: "latest",
      sourceType: "module",
      parserOptions: {
        ecmaFeatures: {
          jsx: true,
        },
      },
      globals: globals.browser,
    },
    plugins: {
      react: reactPlugin,
      "react-hooks": reactHooksPlugin,
    },
    settings: {
      react: {
        version: "detect",
      },
    },
    rules: {
      ...reactPlugin.configs.recommended.rules,
      ...reactHooksPlugin.configs.recommended.rules,
    },
  },
];

Если проект на TypeScript, конфигурацию стоит строить уже вокруг typescript-eslint, а не пытаться натянуть чисто JavaScript-настройку на .ts и .tsx.

Как запускать линтер

Обычно достаточно добавить отдельный скрипт в package.json:

{
  "scripts": {
    "lint": "eslint .",
    "lint:fix": "eslint . --fix"
  }
}

После этого линтер запускается обычной командой:

npm run lint

А автоматические исправления, если они безопасны, так:

npm run lint:fix

Лучше запускать ESLint в CI и в pre-commit или pre-push хуках. Тогда правила становятся частью процесса, а не пожеланием в README.

Когда и как отключать правила

Отключение допустимо, когда правило мешает осознанно, а не потому что “так проще”. Делай это как можно уже по области действия.

Для нескольких строк:

/* eslint-disable no-console */
console.log("debug payload", payload);
console.log("request id", requestId);
/* eslint-enable no-console */

Для одной строки:

console.log("debug payload", payload); // eslint-disable-line no-console

Если отключение повторяется постоянно, почти всегда проблема не в коде, а в конфигурации. Тогда лучше поправить правило один раз, чем размазывать eslint-disable по проекту.

Практическое правило выбора

Хорошая конфигурация ESLint:

  • быстро запускается;
  • ловит реальные ошибки;
  • не спорит с форматтером;
  • не требует постоянных точечных отключений.

Если правило создает шум чаще, чем ловит дефекты, убери его или ослабь. ESLint должен помогать инженерному процессу, а не превращаться в источник фальшивой строгости.