Устаревшие и удалённые правила

Жизненный цикл правила ESLint

Правила в ESLint проходят предсказуемый жизненный цикл, который напрямую связан с эволюцией JavaScript и практик разработки.

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

  • Активное (active) — правило полностью поддерживается, включено в ядро или плагин и соответствует актуальным стандартам.
  • Устаревшее (deprecated) — правило сохраняется в кодовой базе, но его использование не рекомендуется; обычно сопровождается предупреждением и указанием альтернативы.
  • Удалённое (removed) — правило полностью исключено из ESLint или плагина, конфигурации с ним приводят к ошибке при запуске линтера.

Ключевой принцип: устаревание почти всегда предшествует удалению, что даёт время на миграцию.

Причины устаревания правил

Устаревание правил связано не с произвольными решениями, а с изменением экосистемы JavaScript.

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

1. Изменение стандарта ECMAScript

С появлением новых синтаксических возможностей старые ограничения теряют смысл. Например, правила, связанные с обходными паттернами до появления async/await или optional chaining, становятся избыточными.

2. Дублирование функциональности

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

3. Появление конфигурационных альтернатив

Часть логики переносится в более гибкие механизмы:

  • parser options
  • language options
  • project-based type checking (TypeScript ESLint)

4. Поддержка через плагины вместо ядра

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

Поведение устаревших правил

Устаревшие правила обычно:

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

Пример сообщения ESLint:

'old-rule-name' is deprecated. Please use 'new-rule-name' instead.

Типичный процесс замены устаревшего правила

Миграция почти всегда включает три этапа:

1. Обнаружение использования

Поиск через конфигурации:

npx eslint . --print-config src/index.js

или прямой поиск по конфигам:

grep -R "old-rule-name" .

2. Замена правила

Пример замены в конфигурации:

{
  "rules": {
    "old-rule-name": "off",
    "new-rule-name": "error"
  }
}

3. Проверка автоматического исправления

Если правило поддерживает --fix, выполняется:

npx eslint . --fix

Удалённые правила и их последствия

Удалённые правила представляют более критичный уровень изменений.

После удаления:

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

Типичная ошибка:

ESLint configuration error:
Rule "removed-rule" was not found.

Основные причины удаления правил

1. Полное устаревание подхода

Некоторые правила становятся бессмысленными в контексте современного JavaScript.

2. Перенос в плагины

Функциональность сохраняется, но уже вне core:

  • eslint-plugin-import
  • eslint-plugin-promise
  • @typescript-eslint/eslint-plugin

3. Изменение архитектуры ESLint

Переход к flat config (конфигурации без .eslintrc) привёл к пересмотру ряда внутренних механизмов.

4. Поддержка и сопровождение

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

Пример типовой миграции при удалении правила

Конфигурация до:

{
  "rules": {
    "example-rule": "warn"
  }
}

После удаления:

{
  "rules": {
    "example-rule": "off"
  }
}

И замена через альтернативный пакет:

{
  "plugins": ["example-plugin"],
  "rules": {
    "example-plugin/new-rule": "warn"
  }
}

ESLint core vs плагины: влияние на устаревание

Устаревание правил происходит не только в ядре ESLint, но и в экосистеме плагинов.

Разница:

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

Конфигурационные изменения и устаревшие правила

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

Пример flat config:

export default [
  {
    rules: {
      "no-console": "warn"
    }
  }
];

При обновлении ESLint возможны ситуации, когда правило:

  • сохраняется, но меняет поведение;
  • требует явного подключения через @eslint/js;
  • становится недоступным без дополнительных пакетов.

Совместимость версий и влияние на правила

Каждая мажорная версия ESLint может включать:

  • удаление устаревших правил;
  • изменение дефолтных конфигураций (recommended);
  • перенос логики в новые пакеты.

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

  • ESLint v7 → правило активно
  • ESLint v8 → правило deprecated
  • ESLint v9 → правило removed

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

Управление устаревшими правилами в больших проектах

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

Используются следующие практики:

1. Централизованный ESLint-конфиг

Общий пакет конфигурации для всех сервисов:

{
  "extends": ["company/eslint-config"]
}

2. Версионирование конфигурации

Конфиги обновляются синхронно с ESLint:

  • major-версия = изменение правил
  • minor-версия = добавление новых правил
  • patch = корректировки

3. Автоматическая проверка зависимостей

Используются CI-проверки:

npx eslint . --max-warnings=0

4. Регулярная ревизия правил

Удаляются:

  • дублирующие правила;
  • устаревшие настройки;
  • конфликтующие конфигурации.

Совместное использование deprecated и replacement правил

Иногда старое и новое правило могут сосуществовать в переходный период.

Пример:

{
  "rules": {
    "old-rule": "off",
    "new-rule": "error"
  }
}

Такой подход позволяет:

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

Ошибки при работе с удалёнными правилами

На практике встречаются типовые проблемы:

  • обновление ESLint без обновления конфигов;
  • использование старых пресетов (eslint:recommended) в новых версиях;
  • смешивание несовместимых плагинов;
  • отсутствие контроля версий конфигурации.

Стратегия устойчивого обновления правил

Поддержка актуального набора правил требует системного подхода:

  • фиксирование версии ESLint в lockfile;
  • регулярное обновление зависимостей;
  • проверка changelog плагинов;
  • тестирование конфигурации перед деплоем;
  • постепенная миграция deprecated правил до их удаления.

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

Оглавление