Получение и обработка результатов

Результаты работы ESLint представляют собой стандартизированную структуру данных, формируемую после анализа одного или нескольких файлов. Независимо от способа запуска — CLI или программный API — итоговая модель данных сохраняет единый принцип: каждый файл имеет собственный объект результата, содержащий метаинформацию, список проблем и сведения о возможных исправлениях.

Основная единица результата — объект отчёта по файлу:

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

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


Сообщения диагностики (messages)

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

Типичная структура сообщения:

  • ruleId — идентификатор правила ESLint
  • severity — уровень серьёзности (0, 1, 2)
  • message — текстовое описание проблемы
  • line, column — позиция в файле
  • endLine, endColumn — конечная позиция (если применимо)
  • nodeType — тип AST-узла
  • fix — объект автоисправления (если доступно)
  • fatal — критическая ошибка парсинга

Уровни серьёзности

  • 0 — отключено
  • 1 — предупреждение
  • 2 — ошибка

С точки зрения обработки результатов именно severity определяет итоговое поведение CLI и возможность блокировки процесса.


Объект автоисправления (fix)

Если правило поддерживает автоматическое исправление, в сообщении появляется поле fix. Оно описывает изменение исходного кода:

  • range — диапазон символов [start, end]
  • text — строка замены

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

Автоисправления могут пересекаться, что требует дополнительной обработки конфликтов при пакетном применении.


Итоговая структура результата файла

Общий объект результата анализа одного файла включает:

  • filePath — путь к анализируемому файлу
  • messages — массив проблем
  • errorCount — количество ошибок
  • warningCount — количество предупреждений
  • fatalErrorCount — ошибки парсинга
  • fixableErrorCount — количество исправляемых ошибок
  • fixableWarningCount — количество исправляемых предупреждений
  • source — исходный код (опционально)

Эти поля формируются после завершения анализа AST и выполнения всех подключённых правил.


Агрегация результатов

При анализе нескольких файлов ESLint возвращает массив таких объектов. Дополнительно вычисляются агрегированные метрики:

  • общее количество ошибок
  • общее количество предупреждений
  • суммарные фиксы
  • итоговый статус выполнения

Именно агрегированные данные определяют exit code процесса:

  • 0 — проблем нет
  • 1 — найдены ошибки или нарушения правил

CLI-вывод и его обработка

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

Основные форматтеры

  • stylish — человекочитаемый вывод
  • json — структурированный формат для машинной обработки
  • compact — сжатый текстовый формат
  • checkstyle — интеграция с CI-системами
  • html — отчёт в виде HTML-документа

JSON-формат

JSON-вывод является наиболее важным для программной обработки. Он сохраняет структуру результатов без потерь:

  • массив файлов
  • массив сообщений
  • все диагностические поля

Такой формат используется в пайплайнах CI/CD, аналитике качества кода и интеграциях с внешними инструментами.


Обработка результатов через Node.js API

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

Основной класс:

  • ESLint

Методы:

  • lintFiles(patterns) — анализ файлов по glob-шаблонам
  • lintText(code, options) — анализ строки кода

Результат этих методов — массив объектов, идентичных CLI-структуре.

Пример логики обработки

При использовании API важно учитывать:

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

Применение автоисправлений

После получения результатов можно применить исправления к файловой системе.

Используется метод:

  • ESLint.outputFixes(results)

Логика работы:

  1. анализ завершён
  2. собраны fix-объекты
  3. конфликтующие изменения разрешаются
  4. файлы перезаписываются

Важно, что порядок применения влияет на итоговый код, особенно при пересекающихся диапазонах исправлений.


Поток обработки результатов

Типичный процесс обработки можно разложить на этапы:

  1. запуск анализа
  2. получение массива результатов
  3. агрегация статистики
  4. фильтрация сообщений по severity
  5. применение форматтера
  6. (опционально) применение фиксов
  7. формирование exit code

Каждый этап отделён и может быть переопределён в пользовательских сценариях.


Пользовательские форматтеры

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

Форматтер получает на вход массив результатов и возвращает строку.

Внутри доступны все данные:

  • список файлов
  • сообщения
  • статистика
  • фиксируемые ошибки

Это позволяет строить:

  • отчёты для аналитических систем
  • интеграции с внешними dashboard
  • специализированные CI-форматы

Обработка fatal-ошибок

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

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

  • не имеют ruleId
  • всегда имеют fatal: true
  • блокируют дальнейший анализ файла

Такие ошибки учитываются отдельно от стандартных правил и увеличивают fatalErrorCount.


Связь результатов с AST

Каждое сообщение привязано к конкретному узлу AST через nodeType и позиционные данные.

Это позволяет:

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

Результаты не содержат сам AST, но полностью опираются на него как на источник диагностики.


Группировка и фильтрация сообщений

Обработка результатов часто включает агрегацию:

  • группировка по ruleId
  • сортировка по файлам
  • фильтрация по severity
  • выделение исправляемых проблем

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


Интеграция результатов в CI/CD

В CI-средах результаты ESLint интерпретируются как сигнал качества кода:

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

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


Оптимизация обработки больших результатов

При анализе больших кодовых баз структура результатов может содержать тысячи сообщений. Для эффективной обработки используются:

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

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


Расширенные сценарии обработки

На уровне API возможны дополнительные сценарии:

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

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