Свойство settings

Назначение и область применения

Свойство settings в конфигурации ESLint представляет собой глобальное хранилище произвольных данных, доступных всем правилам и плагинам в процессе линтинга. Оно не влияет напрямую на синтаксический анализ кода и не участвует в проверке ECMAScript-спецификации, но используется как механизм передачи контекстной информации между конфигурацией и правилами.

Главная особенность заключается в том, что settings существует вне конкретного файла и вне области отдельного правила, формируя общий контекст анализа проекта.

Ключевые характеристики:

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

Структура и формат

settings представляет собой обычный объект JavaScript, содержащий пары ключ–значение.

Типовая форма:

{
  "settings": {
    "key": "value",
    "nestedKey": {
      "subKey": "value"
    }
  }
}

Допускаются:

  • строки
  • числа
  • булевы значения
  • вложенные объекты
  • массивы (в зависимости от потребления плагином)

Не допускаются:

  • функции
  • классы
  • недетерминированные структуры
  • значения, не сериализуемые в JSON

Механизм передачи данных в правила

Любое правило ESLint получает доступ к конфигурационному контексту через объект context. Внутри него settings доступен как:

context.settings

Пример использования внутри правила:

export default {
  create(context) {
    const config = context.settings.myLibrary || {};

    return {
      Identifier(node) {
        if (config.strictMode && node.name === "eval") {
          context.report({
            node,
            message: "Использование eval запрещено в строгом режиме"
          });
        }
      }
    };
  }
};

Таким образом, settings выступает каналом связи между конфигурацией проекта и логикой правила.

Область видимости и глобальность

settings является глобальным для всего процесса линтинга. Это означает:

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

При этом значения не зависят от конкретного файла, в отличие от parserOptions или overrides.

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

При использовании нескольких конфигурационных уровней (extends, базовые конфиги, локальные настройки) происходит объединение settings.

Основные принципы:

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

Пример:

Базовая конфигурация:

{
  "settings": {
    "env": "production",
    "api": {
      "version": 1
    }
  }
}

Расширяющая конфигурация:

{
  "settings": {
    "api": {
      "version": 2
    }
  }
}

Результат объединения:

{
  "settings": {
    "env": "production",
    "api": {
      "version": 2
    }
  }
}

Использование в плагинах

Плагины активно используют settings для получения информации о проекте, которую невозможно извлечь из AST.

Типовые сценарии:

Определение версии фреймворка

Часто применяется в React-экосистеме:

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

Внутри правил:

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

Настройки резолверов импортов

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

{
  "settings": {
    "import/resolver": {
      "node": {
        "extensions": [".js", ".ts"]
      }
    }
  }
}

Такая конфигурация позволяет:

  • управлять разрешением модулей
  • задавать расширения файлов
  • настраивать алиасы

Общие параметры библиотек

Некоторые плагины используют settings как универсальный канал конфигурации:

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

Отличие от options правил

settings часто путается с options правил, однако между ними существует принципиальное различие:

Характеристика settings options правила
Область глобальная локальная (правило)
Доступ все правила только конкретное правило
Структура свободная строго определена схемой
Назначение контекст проекта настройка поведения правила

Взаимодействие с flat config

В современной системе конфигурации ESLint (flat config) свойство settings сохраняет свою роль и размещается на верхнем уровне конфигурационного объекта.

Пример:

export default [
  {
    settings: {
      debug: true,
      api: {
        endpoint: "https://example.com"
      }
    }
  }
];

Особенности в flat config:

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

Ограничения и особенности поведения

Использование settings сопровождается рядом ограничений:

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

Дополнительная особенность — невозможность реактивного обновления: значения фиксируются на этапе инициализации линтинга.

Типичные паттерны организации

В крупных проектах settings часто структурируется по пространствам имён:

{
  "settings": {
    "react": {
      "version": "detect"
    },
    "import": {
      "internalAliases": ["@/"]
    },
    "project": {
      "strict": true
    }
  }
}

Такой подход снижает вероятность конфликтов между плагинами и упрощает масштабирование конфигурации.

Влияние на производительность и архитектуру

Само наличие settings не влияет на производительность линтинга, однако косвенно может влиять на поведение правил:

  • выбор альтернативных алгоритмов проверки
  • отключение тяжёлых анализов
  • сокращение количества проверок на основе контекста

Архитектурно settings выступает как слой конфигурационного контекста, отделённый от синтаксического анализа кода и логики правил.

Оглавление