Пространство имён правил плагина

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

Базовая структура идентификатора правила

Каждое правило в ESLint имеет строковый идентификатор. В простейшем случае это одиночное имя:

  • no-unused-vars
  • eqeqeq
  • no-console

Такие правила относятся к ядру и не требуют указания источника. Однако при подключении внешних расширений появляется необходимость различать происхождение правил.

Пространство имён плагина

Плагин вводит составной формат идентификатора:

plugin-name/rule-name

Разделение через символ / формирует две логические части:

  • пространство имён (plugin-name) — идентифицирует пакет или набор правил;
  • имя правила (rule-name) — конкретная проверка внутри плагина.

Примеры:

  • react/jsx-uses-react
  • import/no-unresolved
  • node/no-missing-require

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

Семантика пространства имён

Пространство имён выполняет роль контейнера, который связывает правило с его источником. Оно не является частью логики проверки, но критично для:

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

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

Различие между ядром и плагинами

Существует принципиальное разделение:

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

Это различие позволяет ядру оставаться стабильным, а экосистеме расширяться независимо.

Пример сравнения:

Тип Пример
Ядро no-debugger
Плагин @typescript-eslint/no-explicit-any

Во втором случае используется расширенное пространство имён с поддержкой scoped-пакетов npm.

Scoped-имена и двойные пространства

В экосистеме npm часто используются scoped-пакеты, что добавляет дополнительный уровень структуры:

@scope/plugin-name/rule-name

Пример:

  • @typescript-eslint/no-unused-vars

Здесь присутствуют три уровня:

  • @typescript-eslint — npm scope;
  • typescript-eslint — плагин;
  • no-unused-vars — правило.

Такое вложение усиливает уникальность идентификаторов и отражает происхождение пакета.

Разрешение правил при конфигурации

При обработке конфигурационных файлов правило интерпретируется как строковый ключ. Логика загрузки включает:

  1. Разделение строки по символу /.
  2. Определение имени плагина.
  3. Загрузка соответствующего объекта плагина.
  4. Поиск правила внутри экспортируемого набора.

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

Конфликты имён и их устранение

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

  • no-shadow в одном плагине
  • no-shadow в другом

Использование префиксов устраняет неоднозначность:

  • plugin-a/no-shadow
  • plugin-b/no-shadow

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

Роль пространства имён в flat config

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

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

  • ключ объекта — полное имя правила;
  • значение — уровень и параметры;
  • загрузка плагинов выполняется явно.

Несмотря на изменение формата конфигурации, принцип разделения через / остаётся неизменным.

Группировка правил внутри плагина

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

  • import/extensions
  • import/order
  • import/no-cycle

Хотя формально они находятся в одном пространстве имён import, внутреннее разделение отражает категории проверок:

  • разрешение модулей;
  • порядок импортов;
  • циклические зависимости.

Это позволяет поддерживать масштабируемость плагина без усложнения внешнего API.

Интерпретация namespace на уровне архитектуры

С точки зрения архитектуры линтера пространство имён выполняет три функции:

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

Эти функции разделены логически, но реализуются через одну строковую конструкцию.

Влияние на расширяемость экосистемы

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

Структура plugin/rule становится минимальной единицей совместимости между независимыми разработками и ядром линтера, сохраняя предсказуемость поведения при росте числа расширений.

Оглавление