Кеширование: флаг --cache

Назначение механизма кеширования

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

Флаг --cache активирует встроенную систему кеширования результатов линтинга, позволяя ESLint пропускать файлы, которые не изменились с момента последней проверки.

Базовый принцип работы кеша

При включении кеширования ESLint:

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

Кеш хранится в виде файла .eslintcache в корне проекта, если не указано иное.

Стандартное поведение при запуске:

eslint . --cache

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

Структура и расположение кеша

По умолчанию используется файл:

.eslintcache

Он хранит сериализованные данные о:

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

Расположение можно изменить:

eslint . --cache --cache-location ./node_modules/.cache/eslintcache

Это особенно важно для CI-сред или монорепозиториев, где требуется изоляция кеша по проектам.

Поведение при изменении файлов

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

  • изменения конфигурации (.eslintrc, eslint.config.js) могут привести к частичному или полному сбросу кеша;
  • обновление версий плагинов или самих правил также влияет на актуальность кеша;
  • изменение зависимостей интерпретируется как потенциально влияющее на результаты линтинга.

Таким образом, кеш ускоряет процесс, но не гарантирует абсолютной неизменности результатов без пересчёта при изменении окружения.

Стратегии кеширования

ESLint поддерживает различные стратегии кеширования через параметр --cache-strategy.

Основные варианты:

  • metadata — учитываются метаданные файлов (размер, время изменения и т.д.);
  • content — используется хэш содержимого файла (более надёжный подход).

Пример использования:

eslint . --cache --cache-strategy content

Стратегия content обеспечивает более стабильное поведение в условиях CI и при работе с системами контроля версий, где временные метки могут быть ненадёжны.

Производительность и эффект от кеша

Наиболее заметный эффект кеширования проявляется в проектах:

  • с большим количеством файлов (сотни и тысячи модулей);
  • с тяжёлыми правилами (например, анализ AST, импортов, типов);
  • при частых повторных запусках линтера (pre-commit хуки, watch-режим).

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

Использование в CI/CD

В CI-средах кеширование требует осторожности:

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

Типичный подход в CI:

  • либо отключение кеша:
eslint . --no-cache
  • либо использование отдельного пути:
eslint . --cache --cache-location .cache/eslint-ci

При этом кеш может сохраняться как артефакт между job-ами.

Монорепозитории и изоляция кеша

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

Подходы:

  • отдельный кеш-файл для каждого пакета;
  • использование динамического --cache-location:
eslint packages/app --cache --cache-location packages/app/.eslintcache

Это снижает риск коллизий и ускоряет частичные проверки.

Влияние конфигурации ESLint

Любое изменение конфигурационных файлов может привести к сбросу кеша:

  • .eslintrc.*
  • eslint.config.js
  • подключаемые плагины и пресеты

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

Интеграция с инструментами разработки

Кеширование активно используется в связке с:

  • pre-commit инструментами (lint-staged);
  • наблюдателями файлов (watch mode);
  • сборщиками (webpack, Vite, Rollup через плагины ESLint).

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

Ограничения кеширования

Несмотря на эффективность, механизм имеет ограничения:

  • не учитывает изменения в окружении выполнения (Node.js, плагины, резолверы);
  • может требовать полного сброса при обновлении зависимостей;
  • не всегда полезен при одноразовом запуске линтера;
  • увеличивает сложность диагностики при неконсистентных результатах.

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

Поведение при сбросе кеша

Кеш можно принудительно игнорировать:

eslint . --no-cache

В этом режиме ESLint полностью пересчитывает результаты, не используя сохранённые данные. Это используется при:

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