Правила, заменяющие встроенные

Встроенные правила ESLint исторически покрывают базовый набор проблем качества кода: ошибки синтаксиса, потенциально опасные конструкции и минимальные требования к читаемости. Однако по мере развития экосистемы JavaScript стало очевидно, что часть этих правил либо слишком ограничена, либо должна быть расширяема под разные стили кодирования и фреймворки. Это привело к появлению множества правил-заменителей, которые берут на себя функции core-правил или полностью вытесняют их в специализированных конфигурациях и плагинах.

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

Эволюция встроенных правил и перенос ответственности

Встроенные правила ESLint постепенно изменяли свой статус. Часть из них:

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

Наиболее заметный сдвиг произошёл в области стилистических правил. Они больше не рассматриваются как часть основной миссии ESLint, поскольку стиль кода субъективен и зависит от команды.

Конфигурация eslint:recommended включает только те правила, которые считаются критическими для предотвращения ошибок выполнения. Всё остальное выносится в:

  • плагины (eslint-plugin-*);
  • пресеты (plugin:react/recommended, plugin:@typescript-eslint/recommended);
  • отдельные стилистические пакеты.

Такой подход создаёт естественную замену встроенным правилам: вместо расширения core-набора используются специализированные реализации.

Замена стилистических правил через @stylistic

Одним из самых значимых изменений стало выделение стилистических правил в отдельное пространство. Ранее правила вроде:

  • indent
  • quotes
  • semi
  • comma-dangle

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

Современная замена реализована через @stylistic/eslint-plugin.

Пример замены правила

Было (устаревший стиль конфигурации):

{
  "rules": {
    "indent": ["error", 2],
    "quotes": ["error", "single"],
    "semi": ["error", "always"]
  }
}

Стало:

import stylistic from "@stylistic/eslint-plugin";

export default [
  stylistic.configs.recommended
];

При необходимости точечной настройки:

rules: {
  "@stylistic/indent": ["error", 2],
  "@stylistic/quotes": ["error", "single"],
  "@stylistic/semi": ["error", "always"]
}

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

Замена правил через фреймворк-плагины

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

React-экосистема

Правила, связанные с JSX и компонентной моделью, заменяются:

  • eslint-plugin-react
  • eslint-plugin-react-hooks

Например, логика проверки хуков полностью вынесена из ядра и реализована через:

  • react-hooks/rules-of-hooks
  • react-hooks/exhaustive-deps

Это фактически замещает любые гипотетические встроенные проверки React-специфичной логики.

Node.js и серверная среда

Ранее часть проверок, связанных с окружением Node.js, находилась в core-экосистеме. Сейчас их заменяет:

  • eslint-plugin-n

Он включает правила, которые контролируют:

  • использование process
  • корректность модулей CommonJS/ESM
  • работу с файловой системой

Пример замены логики:

{
  "rules": {
    "n/no-missing-import": "error",
    "n/no-unpublished-require": "error"
  }
}

Импорт и модульная структура

Работа с импортами вынесена в:

  • eslint-plugin-import

Он заменяет и расширяет базовые проверки модулей:

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

Пример:

{
  "rules": {
    "import/no-cycle": "error",
    "import/order": "error"
  }
}

Flat config и переосмысление замены встроенных правил

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

Пример:

import js from "@eslint/js";
import react from "eslint-plugin-react";

export default [
  js.configs.recommended,
  react.configs.flat.recommended
];

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

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

При использовании альтернативных правил важно учитывать возможные конфликты:

  1. Дублирование логики Одно и то же правило может существовать в core и plugin-версии.

  2. Разная строгость Plugin-реализация часто строже, чем устаревший core-аналог.

  3. Разные зоны ответственности Core проверяет синтаксис, плагины — семантику и архитектуру.

Для устранения конфликтов обычно отключают core-правило:

{
  "rules": {
    "indent": "off",
    "@stylistic/indent": "error"
  }
}

Карта соответствий: встроенные правила и их замены

Стилистические правила

  • indent → @stylistic/indent
  • quotes → @stylistic/quotes
  • semi → @stylistic/semi
  • comma-dangle → @stylistic/comma-dangle

Архитектурные и модульные проверки

  • встроенные базовые проверки модулей → eslint-plugin-import
  • node-окружение → eslint-plugin-n

Фреймворк-логика

  • отсутствует в core → eslint-plugin-react, eslint-plugin-vue

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

Некоторые core-правила утратили универсальность:

  • они фиксируют стиль, а не ошибки;
  • требуют постоянного обновления под новые стандарты;
  • не учитывают специфику фреймворков;
  • конфликтуют с форматтерами (Prettier, Biome).

В результате такие правила либо становятся обёртками над внешними реализациями, либо полностью заменяются.

Взаимодействие с форматтерами и эффект вытеснения правил

Современные форматтеры берут на себя часть задач ESLint. Это приводит к тому, что:

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

Например, использование Prettier фактически заменяет необходимость:

  • indent
  • quotes
  • semi

в ESLint-конфигурации.

Паттерны миграции на заменяющие правила

Типичный переход включает:

  • отключение core-правила;
  • подключение plugin-аналогов;
  • проверку конфликтов;
  • унификацию конфигурации через preset.

Пример миграции:

{
  "rules": {
    "no-unused-vars": "error",
    "quotes": "off",
    "@stylistic/quotes": ["error", "single"]
  }
}

Роль пресетов в замене встроенной логики

Пресеты становятся механизмом массовой замены правил. Они позволяют:

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

Примеры:

  • eslint:recommended
  • plugin:@typescript-eslint/recommended
  • plugin:@stylistic/recommended

Каждый из них фактически перекрывает часть встроенного поведения ESLint.

Переход от монолитных правил к модульной экосистеме

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

  • core → минимальная база;
  • plugins → расширение;
  • configs → композиция поведения.

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

Оглавление