Секция rules: синтаксис и уровни

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

Базовый синтаксис секции rules

В классическом формате конфигурации (.eslintrc) секция представляет собой объект, где ключ — имя правила, а значение — его настройка:

{
  "rules": {
    "no-unused-vars": "error",
    "eqeqeq": "warn",
    "curly": "error"
  }
}

Каждое правило идентифицируется строкой вида plugin/rule-name или просто rule-name, если оно встроенное.

Форматы задания правила

Существует несколько допустимых форматов записи:

  1. Строковый формат
"no-console": "off"
  1. Числовой формат
"no-console": 0
  1. Массив с настройками
"eqeqeq": ["error", "always"],
"quotes": ["warn", "single"]

Массив используется, когда правило поддерживает дополнительные параметры.

Уровни строгости правил

Каждое правило в ESLint имеет уровень строгости, который определяет реакцию линтера на нарушение.

off / 0

Полное отключение правила.

"no-debugger": "off"

или

"no-debugger": 0

Характеристика:

  • правило не выполняется
  • ошибки игнорируются
  • не влияет на процесс проверки

Используется для локального подавления ненужных проверок или временного отключения во время разработки.

warn / 1

Предупреждение без остановки процесса.

"no-unused-vars": "warn"

или

"no-unused-vars": 1

Особенности:

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

Типичный сценарий — мягкое внедрение новых стандартов без блокировки разработки.

error / 2

Критический уровень.

"eqeqeq": "error"

или

"eqeqeq": 2

Поведение:

  • нарушение считается ошибкой
  • может блокировать сборку
  • часто используется в CI/CD пайплайнах

Этот уровень применяется для правил, влияющих на корректность выполнения программы или критические дефекты.

Расширенный синтаксис правил с параметрами

Многие правила поддерживают дополнительную конфигурацию через массив:

{
  "quotes": ["error", "single", { "avoidEscape": true }]
}

Структура массива:

  1. Первый элемент — уровень (off | warn | error)
  2. Второй элемент — основной режим работы правила
  3. Третий элемент и далее — дополнительные опции

Пример: eqeqeq

{
  "eqeqeq": ["error", "always"]
}

Здесь:

  • error — уровень строгости
  • always — режим, требующий строгого сравнения ===

Пример: no-console с исключениями

{
  "no-console": ["warn", { "allow": ["warn", "error"] }]
}

Такой подход позволяет:

  • разрешить часть вызовов console
  • оставить остальные под контролем линтера

Наследование и переопределение правил

В реальных проектах правила редко задаются в одном месте. Они объединяются из нескольких источников:

  • базовые конфигурации
  • плагины
  • расширения (extends)
  • локальные переопределения

Пример:

{
  "extends": "eslint:recommended",
  "rules": {
    "no-console": "off",
    "eqeqeq": "error"
  }
}

Механизм работает по принципу приоритета: локальные правила всегда перекрывают наследуемые.

Правила из плагинов

Плагины добавляют собственные правила, которые подключаются через префикс:

{
  "rules": {
    "react/jsx-key": "error",
    "import/no-unresolved": "error"
  }
}

Структура имени:

pluginName/ruleName

Особенности:

  • требуют подключения соответствующего плагина
  • могут иметь собственные наборы опций
  • часто включают более специализированную проверку кода

Группировка и масштабирование конфигурации

В крупных проектах секция rules может содержать десятки и сотни правил. Для управления используют:

Логическое разделение

{
  "rules": {
    // ошибки
    "no-undef": "error",
    "no-unused-vars": "error",

    // стиль
    "quotes": "warn",
    "semi": "warn"
  }
}

Использование комментариев (в JSONC / JS-конфиге)

module.exports = {
  rules: {
    // потенциальные ошибки
    "no-eval": "error",

    // предпочтения стиля
    "camelcase": "warn"
  }
}

Совместимость уровней и числовых значений

ESLint допускает эквивалентные формы записи:

Уровень Строка Число
off “off” 0
warn “warn” 1
error “error” 2

Числовая форма исторически сохраняется для обратной совместимости, но строковая считается более читаемой.

Переопределение правил в разных контекстах

В конфигурациях поддерживаются локальные изменения через overrides:

{
  "overrides": [
    {
      "files": ["*.test.js"],
      "rules": {
        "no-unused-expressions": "off"
      }
    }
  ]
}

Такой механизм позволяет:

  • отключать строгие правила в тестах
  • изменять поведение для конкретных директорий
  • поддерживать разные стандарты внутри одного проекта

Влияние порядка и приоритетов

При объединении конфигураций действует следующая логика:

  1. базовые конфиги (extends)
  2. плагины
  3. локальный rules
  4. overrides

Каждый следующий слой перекрывает предыдущий.

Типичные ошибки при конфигурации rules

Конфликт форматов

"quotes": "error",
"quotes": ["warn", "single"]

Последнее значение перезапишет первое.

Отсутствие плагина

"react/jsx-uses-react": "error"

без подключения eslint-plugin-react приводит к ошибке загрузки конфигурации.

Неверная структура массива

"eqeqeq": ["error", "always", "extra", "value"]

Лишние параметры игнорируются или приводят к непредсказуемому поведению в зависимости от правила.

Концепция семантики правил

Каждое правило в системе ESLint представляет собой независимый модуль, который:

  • анализирует AST (Abstract Syntax Tree)

  • применяет набор проверок

  • возвращает результат в виде:

    • ошибки
    • предупреждения
    • отсутствия нарушений

Секция rules лишь управляет тем, как интерпретировать результат работы этих модулей, но не определяет их внутреннюю логику.

Гибкость конфигурации как ключевой механизм

Система уровней и синтаксиса позволяет строить конфигурации различной строгости:

  • мягкие профили (много warn)
  • строгие корпоративные стандарты (почти все error)
  • экспериментальные конфигурации (точечные off для временных исключений)

Такой подход делает систему линтинга адаптируемой к различным стадиям разработки и требованиям проекта.

Оглавление