Опции --cache-location и --cache-strategy

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

Кэширование управляется несколькими CLI-параметрами, среди которых ключевыми являются --cache-location и --cache-strategy. Они отвечают за разные аспекты хранения и интерпретации кэшированных данных: первый определяет физическое расположение кэша, второй — логику того, какие изменения считаются значимыми для инвалидирования результатов.

--cache-location: управление местом хранения кэша

Параметр --cache-location задаёт путь к файлу, в котором ESLint сохраняет кэш результатов предыдущего запуска.

Базовое поведение

По умолчанию ESLint создаёт файл кэша в локальной файловой системе проекта, обычно:

  • .eslintcache

Этот файл располагается в текущей рабочей директории и используется повторно при последующих запусках.

Явное указание пути

eslint . --cache --cache-location ./tmp/eslint-cache.json

В этом случае кэш переносится в пользовательское расположение. Это особенно важно в следующих сценариях:

  • CI/CD окружения, где требуется изоляция кэша между джобами
  • монорепозитории, где кэш удобнее централизовать
  • использование временных файловых систем (например, /tmp)
  • разделение кэша между разными конфигурациями ESLint

Особенности хранения

Кэш-файл содержит сериализованную информацию о состоянии файлов, включая:

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

Формат кэша не предназначен для ручного редактирования и может изменяться между версиями ESLint.

Поведение при изменении пути

Изменение --cache-location приводит к:

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

Это важно учитывать при переключении окружений или веток разработки.

--cache-strategy: логика инвалидирования кэша

Параметр --cache-strategy определяет, по каким критериям ESLint считает файл изменённым и требует повторного анализа.

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

metadata (стратегия по умолчанию)

Использует файловые метаданные, такие как:

  • время изменения (mtime)
  • размер файла
  • базовые признаки изменения файловой системы

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

  • высокая скорость проверки
  • возможны ложные попадания в кэш при изменениях без обновления mtime
  • зависит от точности файловой системы

Подходит для большинства локальных сценариев разработки.

content

Основана на сравнении содержимого файлов через хеширование.

Механизм работы:

  • читается содержимое файла
  • вычисляется хеш (обычно SHA-подобный алгоритм)
  • сравнивается с ранее сохранённым значением

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

  • более точная детекция изменений
  • медленнее metadata из-за необходимости чтения файлов
  • устойчивость к некорректным mtime (например, при копировании файлов)

Применяется в средах, где файловые метаданные ненадёжны:

  • сетевые файловые системы
  • контейнеризированные окружения
  • Windows Subsystem for Linux при синхронизации файлов

Взаимодействие --cache-location и --cache-strategy

Оба параметра работают совместно и определяют разные уровни кэширования:

  • --cache-location отвечает за где хранится кэш
  • --cache-strategy отвечает за как он считается валидным

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

eslint src --cache \
  --cache-location ./node_modules/.cache/eslint.json \
  --cache-strategy content

Такое сочетание часто используется в монорепозиториях с несколькими пакетами, где важно:

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

Поведение в различных средах выполнения

Локальная разработка

Чаще используется стратегия metadata, так как:

  • файловая система локальна и надёжна
  • важна максимальная скорость
  • изменения фиксируются корректно через mtime

CI/CD

В CI часто:

  • кэш либо отключается
  • либо используется content для надёжности

Причина — нестабильность временных меток и возможное кэширование артефактов между сборками.

Монорепозитории

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

  • общий кэш может приводить к конфликтам
  • используется кастомный --cache-location на пакет или workspace
  • иногда комбинируется с content для точности

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

metadata

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

content

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

Разница становится заметной при:

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

Типичные проблемы и особенности поведения

Инвалидация кэша при изменении конфигурации

Любое изменение:

  • .eslintrc
  • подключённых плагинов
  • парсеров

может привести к полной инвалидции кэша, даже если --cache-location остаётся тем же.

Несовместимость кэша между версиями ESLint

Кэш-файл не является стабильным API. Обновление ESLint может:

  • сделать старый кэш недействительным
  • привести к полной пересборке состояния

Конфликты при параллельном запуске

Если несколько процессов используют один --cache-location:

  • возможна гонка записи
  • повреждение кэша
  • частичная инвалидция данных

Решение заключается в разнесении путей кэша по процессам или пакетам.

Практическая интерпретация различий стратегий

Параметр Основа проверки Скорость Точность Типичный сценарий
metadata файловые метаданные высокая средняя локальная разработка
content хеш содержимого ниже высокая CI, сетевые FS

Поведение при отключении --cache

При отсутствии --cache:

  • --cache-location игнорируется
  • --cache-strategy не применяется
  • каждый запуск выполняет полный анализ файлов

Это делает оба параметра строго вспомогательными по отношению к флагу --cache.

Оглавление