Порядок применения и приоритеты

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

В основе лежит принцип: более специфичная и поздно применённая настройка имеет приоритет над более общей.

Базовая модель приоритетов

При обработке конфигурации формируется цепочка источников:

  • встроенные дефолтные значения
  • конфигурации из extends
  • плагины и их рекомендуемые наборы правил
  • локальная конфигурация проекта
  • секции overrides
  • CLI-параметры запуска

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

Порядок применения в extends

Механизм extends задаёт последовательное наследование конфигураций. Каждый следующий элемент массива применяется поверх предыдущего.

Пример логики:

  1. базовый preset (например, eslint:recommended)
  2. конфигурация плагина (например, plugin:react/recommended)
  3. пользовательский конфиг проекта

Ключевая особенность заключается в том, что конфликтующие правила не объединяются, а заменяются по ключу. Если одно и то же правило встречается несколько раз, остаётся значение из последнего применённого источника.

Приоритет правил

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

Иерархия приоритета правил

  1. CLI параметры (--rule)
  2. overrides в конфигурации
  3. основная конфигурация проекта
  4. extends
  5. рекомендации плагинов
  6. встроенные значения

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

Поведение overrides

Секция overrides создаёт контекстно-зависимые конфигурации. Она применяется после основной конфигурации, но только к файлам, соответствующим указанным шаблонам.

Логика применения:

  • базовая конфигурация применяется ко всем файлам
  • затем проверяются правила overrides
  • если файл совпадает с files или не попадает в excludedFiles, его конфигурация модифицируется

Приоритет внутри overrides также линейный: последний совпавший блок имеет больший вес.

Влияние CLI-параметров

Запуск линтера через командную строку может переопределять конфигурацию проекта.

Наиболее значимые параметры:

  • --rule — прямое переопределение конкретного правила
  • --config — указание альтернативного конфигурационного файла
  • --ext — выбор расширений файлов
  • --ignore-pattern — добавление временных исключений

CLI-настройки имеют наивысший приоритет, так как применяются после загрузки всех конфигураций.

Конфигурации плагинов

Плагины предоставляют наборы правил и предустановок. Эти наборы подключаются через extends.

Особенность заключается в том, что плагины:

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

Если плагин и проект задают одно правило, итоговое значение определяется проектом.

Влияние parserOptions, env и globals

Эти параметры не являются правилами, но влияют на интерпретацию кода.

parserOptions

Формируют контекст парсинга:

  • версия ECMAScript
  • тип модулей
  • JSX и экспериментальные синтаксисы

env

Определяет предустановленные глобальные переменные среды выполнения.

globals

Добавляет или переопределяет глобальные идентификаторы.

При конфликте между env и globals приоритет получает globals, так как он более явный и точечный.

Порядок обработки ignore-правил

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

Последовательность:

  1. .eslintignore
  2. ignorePatterns в конфигурации
  3. --ignore-pattern из CLI

CLI-игнорирование имеет наивысший приоритет и применяется последним, окончательно исключая файлы из анализа.

Влияние processor и overrides на файлы

Processors изменяют способ разбиения файлов на части (например, HTML с встроенным JS). После применения processor-а каждый сегмент проходит собственную цепочку конфигурации.

При этом:

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

Сложение и замещение конфигураций

Конфигурации не складываются арифметически. Используется модель:

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

Пример поведения:

  • rules: перезапись по ключу
  • env: объединение ключей с приоритетом последнего значения
  • globals: переопределение по имени глобала

Приоритет в flat config

В современных версиях ESLint используется плоская конфигурация (flat config), где порядок файлов конфигурации становится критическим.

Модель работы:

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

В flat config отсутствует классическая цепочка extends, вместо неё используется явное перечисление конфигурационных объектов, что делает порядок записи единственным источником приоритета.

Конфликтующие правила в разных слоях

При пересечении нескольких источников применяется детерминированная схема:

  • одинаковые правила → последнее определение побеждает
  • отсутствующие правила → наследуются без изменений
  • отключённые правила ("off") всегда перекрывают включённые значения

Особый случай — конфигурации плагинов, где "recommended" наборы могут быть полностью переопределены локальными настройками.

Приоритет файлов конфигурации

Если существует несколько конфигурационных файлов:

  • eslint.config.js (flat config)
  • .eslintrc.js
  • .eslintrc.json
  • .eslintrc.yaml

выбирается только один механизм в зависимости от режима работы. В смешанных сценариях приоритет отдаётся flat config, а legacy-конфигурации игнорируются.

Поведение при множественных источниках конфигурации

Когда конфигурация собирается из нескольких пакетов:

  • сначала загружаются плагины
  • затем extends
  • затем локальная конфигурация
  • затем overrides
  • затем CLI

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

Приоритет в сложных сценариях с несколькими overrides

Если несколько overrides совпадают с файлом:

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

Таким образом, последний совпавший блок определяет итоговое поведение для каждого конкретного правила.

Итоговая модель разрешения конфликтов

Сводная логика приоритетов:

  • CLI
  • overrides
  • локальная конфигурация
  • flat config порядок или extends-цепочка
  • плагины
  • встроенные значения

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

Оглавление