Конфигурации recommended и strict

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

Набор eslint:recommended включается через поле extends и активирует фиксированный список правил, отмеченных как рекомендуемые в ядре ESLint. Эти правила обновляются между мажорными версиями и отражают консенсус о наиболее критичных проблемах в JavaScript-коде.

Основная цель конфигурации — выявление ошибок, которые:

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

Типичные категории правил:

1. Ошибки переменных

  • использование необъявленных переменных
  • повторное объявление
  • неиспользуемые переменные (в базовой форме)

2. Ошибки синтаксиса и логики

  • недостижимый код
  • неправильные return-выражения
  • некорректные условия в ветвлениях

3. Безопасность и предсказуемость

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

Поведение в конфигурации

При включении:

{
  "extends": "eslint:recommended"
}

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

Характеристика подхода

Конфигурация recommended в ESLint характеризуется следующими свойствами:

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

Строгая конфигурация (strict)

Понятие «strict» в контексте ESLint не является официальным встроенным пресетом, однако используется как архитектурный паттерн конфигурации, основанный на усилении стандартных правил до максимально жёсткого уровня контроля качества.

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

  • расширение eslint:recommended с дополнительными правилами;
  • использование eslint:all с последующей выборочной деактивацией;
  • кастомный набор правил в рамках организации;
  • комбинация с TypeScript-правилами и плагинами.

Принцип построения strict-конфигурации

Строгая модель ориентируется не только на предотвращение ошибок, но и на:

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

Типичное расширение включает:

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

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

{
  "extends": ["eslint:recommended"],
  "rules": {
    "no-console": "error",
    "no-unused-vars": "error",
    "eqeqeq": "error",
    "curly": "error",
    "no-var": "error"
  }
}

Расширение до уровня архитектурной строгости

В более жёстких наборах добавляются правила, влияющие на стиль программирования:

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

Также часто вводятся лимиты:

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

Уровень контроля

recommended:

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

strict:

  • контролирует как ошибки, так и стиль;
  • навязывает единообразие;
  • влияет на структуру кода.

Область применения

recommended в ESLint:

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

strict:

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

Поведение в CI

При recommended пайплайн обычно реагирует только на критические ошибки выполнения.

При strict-конфигурации блокировка происходит при нарушении даже стилистических или архитектурных правил, что повышает стабильность, но снижает свободу разработки.

Взаимодействие с плагинами

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

  • eslint-plugin-import для контроля импортов;
  • eslint-plugin-promise для корректного использования промисов;
  • eslint-plugin-sonarjs для анализа сложности;
  • @typescript-eslint для строгой типизации.

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

Принципы эволюции конфигурации

Переход от recommended к strict обычно происходит постепенно:

  1. включение базового eslint:recommended;
  2. добавление критичных правил качества;
  3. внедрение ограничений на стиль;
  4. подключение метрик сложности;
  5. интеграция кастомных организационных правил.

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

Поведение в реальных проектах

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

При этом strict-набор правил влияет не только на качество кода, но и на процесс разработки:

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

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

Оглавление