eslint:recommended и eslint:all

ESLint предоставляет наборы предустановленных правил, позволяющих быстро подключить готовую конфигурацию без необходимости вручную перечислять десятки или сотни правил. Наиболее известными встроенными конфигурациями являются eslint:recommended и eslint:all.

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

Назначение встроенных конфигураций

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

Встроенные конфигурации позволяют:

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

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

Пример для классической конфигурации:

module.exports = {
    extends: ["eslint:recommended"]
};

Для Flat Config:

import js from "@eslint/js";

export default [
    js.configs.recommended
];

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

Общая характеристика

eslint:recommended представляет собой набор правил, рекомендуемых командой ESLint для большинства проектов.

В данную конфигурацию включены правила, которые:

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

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

Что входит в eslint:recommended

Конкретный список правил может изменяться между версиями ESLint, однако обычно в него входят проверки следующих категорий:

Использование неопределённых переменных

function calculate() {
    return total;
}

Ошибка:

'total' is not defined

Правило:

no-undef

Недостижимый код

function test() {
    return true;

    console.log("never executed");
}

Правило:

no-unreachable

Такой код никогда не будет выполнен.

Дублирование условий

if (value === 1) {
    console.log("one");
} else if (value === 1) {
    console.log("again");
}

Правило:

no-dupe-else-if

Условие никогда не достигнет второй ветки.

Повторное объявление переменных

let count = 1;
let count = 2;

Правило:

no-redeclare

Ошибки в конструкциях цикла

for (
    let i = 0;
    i < 10;
) {
    console.log(i);
}

Некорректная структура цикла будет обнаружена соответствующими правилами синтаксической проверки.

Неверное использование конструкторов

new Symbol("id");

Правило:

no-new-native-nonconstructor

Некоторые встроенные объекты не предназначены для вызова через new.

Проверка операторов сравнения

if (value = 10) {
    console.log("test");
}

Здесь используется присваивание вместо сравнения.

Правило:

no-cond-assign

Преимущества eslint:recommended

Минимум ложных срабатываний

Правила включаются только после длительного обсуждения и анализа практического опыта использования ESLint.

Поэтому большинство предупреждений действительно указывают на ошибки.

Простота внедрения

Достаточно подключить одну строку:

extends: ["eslint:recommended"]

После этого проект получает десятки полезных проверок.

Безопасность обновлений

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

Подходит для любого стиля кодирования

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

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

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

Когда использовать eslint:recommended

Конфигурация подходит практически для всех проектов:

  • корпоративных приложений;
  • серверов на Node.js;
  • фронтенд-проектов;
  • библиотек;
  • учебных проектов;
  • микросервисов.

Очень часто она становится основой всей конфигурации ESLint.

Пример:

module.exports = {
    extends: ["eslint:recommended"],

    rules: {
        "no-console": "warn",
        "eqeqeq": "error"
    }
};

Здесь используются рекомендации ESLint и дополнительно подключаются собственные требования проекта.

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

Общая характеристика

eslint:all включает абсолютно все правила, доступные в текущей версии ESLint.

Подключение:

module.exports = {
    extends: ["eslint:all"]
};

Для Flat Config:

import js from "@eslint/js";

export default [
    js.configs.all
];

В отличие от eslint:recommended, данная конфигурация активирует не только правила поиска ошибок, но и:

  • правила стилистики;
  • правила читаемости;
  • правила форматирования;
  • экспериментальные проверки;
  • спорные рекомендации.

Принцип работы eslint:all

После подключения будут активированы все встроенные правила ESLint.

Например:

const name = "John";

Могут появиться предупреждения, связанные с:

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

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

Особенности eslint:all

Включаются правила оформления

Например:

if (isReady)
    start();

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

if (isReady) {
    start();
}

Включаются спорные рекомендации

Некоторые команды предпочитают один стиль программирования, другие — противоположный.

Например:

const fn = () => {};

или

function fn() {}

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

Конфигурация меняется между версиями

Это одна из самых важных особенностей.

После обновления ESLint:

npm update eslint

в конфигурацию автоматически попадут новые правила.

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

Недостатки eslint:all

Нестабильность

Предположим, в версии ESLint добавлено новое правило:

new-rule

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

Поведение линтера изменится даже без редактирования конфигурации.

Большое количество предупреждений

Даже небольшой проект может получить десятки или сотни сообщений:

120 warnings
34 errors

Часть из них будет связана исключительно со стилем оформления.

Сложность поддержки

Для реального проекта часто приходится отключать большое количество правил:

module.exports = {
    extends: ["eslint:all"],

    rules: {
        "rule-a": "off",
        "rule-b": "off",
        "rule-c": "off",
        "rule-d": "off",
        "rule-e": "off"
    }
};

Со временем такой файл становится трудным для сопровождения.

Когда использовать eslint:all

На практике конфигурация применяется значительно реже.

Типичные сценарии:

Изучение возможностей ESLint

Конфигурация позволяет увидеть полный набор доступных правил:

extends: ["eslint:all"]

После запуска линтера становится понятно, какие проверки существуют.

Формирование собственной конфигурации

Иногда проект начинает работу с eslint:all, после чего постепенно отключаются ненужные правила.

В результате формируется собственный набор требований.

Аудит качества кода

Полная проверка позволяет выявить:

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

Сравнение eslint:recommended и eslint:all

Характеристика eslint:recommended eslint:all
Поиск ошибок Да Да
Проверка стиля Частично Полностью
Подходит для большинства проектов Да Нет
Стабильность между версиями Высокая Низкая
Количество предупреждений Умеренное Очень большое
Простота внедрения Высокая Низкая
Требует дополнительной настройки Минимально Значительно
Использование в production Рекомендуется Обычно не рекомендуется

Практический пример выбора

Для большинства проектов предпочтительным вариантом считается следующая схема:

module.exports = {
    extends: ["eslint:recommended"],

    rules: {
        "eqeqeq": "error",
        "no-console": "warn",
        "curly": "error"
    }
};

Такой подход обеспечивает:

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

Использование eslint:all обычно оправдано лишь как временный инструмент анализа или источник для построения собственной конфигурации.

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

Часто eslint:recommended выступает базовым уровнем проверки, поверх которого подключаются дополнительные конфигурации.

Пример:

module.exports = {
    extends: [
        "eslint:recommended",
        "plugin:import/recommended",
        "plugin:promise/recommended"
    ]
};

В этом случае:

  1. Сначала применяются рекомендации ESLint.
  2. Затем подключаются правила для импортов.
  3. После этого добавляются проверки работы с Promise.

Такой подход обеспечивает постепенное расширение набора правил без необходимости использовать агрессивную конфигурацию eslint:all.

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

Разница в скорости работы между двумя конфигурациями может быть заметна на крупных проектах.

eslint:recommended активирует ограниченный набор наиболее важных правил, поэтому проверка выполняется быстрее.

eslint:all запускает каждое встроенное правило ESLint, что увеличивает:

  • время анализа файлов;
  • потребление памяти;
  • нагрузку на CI/CD-пайплайны.

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

Рекомендации по выбору

Для подавляющего большинства производственных проектов оптимальным выбором является eslint:recommended.

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

eslint:all следует рассматривать как инструмент исследования возможностей линтера, аудита кода или построения собственной конфигурации. Использование её в качестве постоянной основы проекта приводит к избыточному количеству предупреждений, усложняет сопровождение конфигурации и делает поведение линтера зависимым от изменений в новых версиях ESLint.

Оглавление