Поля конфигурационного файла

Конфигурационный файл ESLint определяет правила анализа кода, набор подключаемых плагинов, среду выполнения и параметры интерпретации JavaScript/TypeScript. Современная система конфигурации опирается на файл eslint.config.js (Flat Config), однако в экосистеме по-прежнему встречаются форматы .eslintrc.*, где структура определяется набором стандартных полей.

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

Основная структура конфигурации

Базовая конфигурация описывает набор параметров, которые ESLint использует при анализе файлов:

  • parser — определяет парсер JavaScript/TypeScript
  • rules — набор правил проверки кода
  • env — окружение выполнения
  • globals — глобальные переменные
  • plugins — подключаемые расширения
  • extends — наследование конфигураций
  • parserOptions — параметры разбора кода

Каждое из этих полей влияет на разные стадии анализа: от синтаксического разбора до применения правил.

Поле parser

Поле parser определяет, какой парсер используется для анализа исходного кода.

По умолчанию ESLint использует собственный парсер Espree, поддерживающий современный JavaScript. Однако при работе с расширениями синтаксиса (TypeScript, JSX, экспериментальные фичи) используется альтернативный парсер.

Типичные значения:

  • espree — стандартный парсер ESLint
  • @typescript-eslint/parser — для TypeScript
  • babel-eslint (устаревший) — интеграция с Babel

Пример:

export default [
  {
    languageOptions: {
      parser: require("@typescript-eslint/parser")
    }
  }
];

Выбор парсера определяет доступный синтаксис. Например, без соответствующего парсера ESLint не сможет обработать TypeScript-интерфейсы или JSX-структуры.

Поле parserOptions

parserOptions уточняет поведение выбранного парсера и управляет тем, как код интерпретируется.

Основные параметры:

  • ecmaVersion — версия ECMAScript (например, 2020, 2022, latest)
  • sourceType — тип модуля (script или module)
  • ecmaFeatures — дополнительные возможности языка
  • project — путь к tsconfig.json (для TypeScript)

Пример:

export default [
  {
    languageOptions: {
      parserOptions: {
        ecmaVersion: "latest",
        sourceType: "module",
        ecmaFeatures: {
          jsx: true
        }
      }
    }
  }
];

Поле sourceType: "module" включает поддержку import/export. Без этого ESLint будет трактовать код как обычный скрипт.

Поле rules

rules — центральная часть конфигурации ESLint, определяющая поведение линтера.

Каждое правило задаётся парой:

  • имя правила
  • уровень строгости или конфигурационный массив

Уровни:

  • "off" или 0 — отключено
  • "warn" или 1 — предупреждение
  • "error" или 2 — ошибка

Пример:

rules: {
  "no-unused-vars": "error",
  "eqeqeq": "warn",
  "semi": ["error", "always"]
}

Правила могут иметь дополнительные параметры. Например, semi принимает конфигурацию поведения:

  • "always" — обязательные точки с запятой
  • "never" — запрещены

Расширенный формат:

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

Поле env

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

Примеры окружений:

  • browser — браузерные глобальные объекты (window, document)
  • node — Node.js окружение
  • es2021 — современные ECMAScript глобалы
  • jest — тестовая среда

Пример:

env: {
  browser: true,
  node: true,
  es2021: true
}

Каждое включённое окружение влияет на набор допустимых глобальных переменных. Например, без node: true использование process будет считаться ошибкой.

Поле globals

globals используется для явного объявления глобальных переменных, которые не должны вызывать предупреждений ESLint.

Каждая переменная задаётся с указанием её изменяемости:

  • "readonly" — только для чтения
  • "writable" — разрешено изменение

Пример:

globals: {
  MY_GLOBAL: "readonly",
  DEBUG_MODE: "writable"
}

Это поле часто применяется в проектах с интеграцией сторонних скриптов или при использовании глобальных объектов, предоставляемых окружением сборки.

Поле plugins

plugins подключает расширения ESLint, добавляющие новые правила и возможности анализа.

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

Пример:

plugins: {
  react: require("eslint-plugin-react"),
  "@typescript-eslint": require("@typescript-eslint/eslint-plugin")
}

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

rules: {
  "react/jsx-uses-react": "error"
}

Плагины являются ключевым механизмом расширения ESLint для фреймворков и библиотек.

Поле extends

extends позволяет наследовать готовые конфигурации.

Это могут быть:

  • встроенные конфигурации ESLint
  • конфигурации сторонних пакетов
  • корпоративные стандарты

Примеры:

extends: [
  "eslint:recommended",
  "plugin:react/recommended"
]

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

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

Поле settings

settings передаёт произвольные данные плагинам ESLint. Эти данные не используются самим ESLint, но доступны внутри правил плагинов.

Пример:

settings: {
  react: {
    version: "detect"
  }
}

В данном случае плагин React автоматически определяет версию библиотеки и адаптирует правила под неё.

Поле ignorePatterns

ignorePatterns определяет файлы и директории, исключаемые из анализа.

Пример:

ignorePatterns: [
  "node_modules/",
  "dist/",
  "*.min.js"
]

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

Поле overrides

overrides позволяет применять разные правила к разным наборам файлов.

Структура:

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

Также возможно использование условий:

  • разные парсеры
  • разные окружения
  • разные плагины

Это поле особенно важно в монорепозиториях и проектах с разными типами исходников.

Поле root

root предотвращает поиск конфигураций ESLint в родительских директориях.

root: true

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

Поле noInlineConfig

noInlineConfig запрещает использование inline-комментариев ESLint:

/* eslint-disable */

или

/* eslint-enable */

Пример:

noInlineConfig: true

Это используется в строгих средах, где требуется централизованное управление правилами.

Поле reportUnusedDisableDirectives

reportUnusedDisableDirectives включает проверку неиспользуемых отключений ESLint.

reportUnusedDisableDirectives: true

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

Flat Config: современная структура полей

В Flat Config структура несколько изменяется. Вместо env, parserOptions и части других полей используется единая модель languageOptions.

Пример:

export default [
  {
    languageOptions: {
      ecmaVersion: "latest",
      sourceType: "module",
      globals: {
        window: "readonly"
      },
      parser: require("@typescript-eslint/parser")
    },
    rules: {
      "no-console": "warn"
    }
  }
];

Основные изменения:

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

Взаимодействие полей конфигурации

Поля конфигурации не существуют изолированно. Их взаимодействие формирует итоговое поведение линтера.

  • parser + parserOptions определяют синтаксис
  • env + globals задают контекст выполнения
  • plugins + rules формируют логику проверки
  • extends влияет на базовый набор всех параметров
  • overrides может переопределить любую часть конфигурации

Итоговое поведение ESLint представляет собой результат последовательного объединения этих слоёв, где более специфичные настройки перекрывают общие.

Оглавление