Кеширование в ESLint представляет собой слой оптимизации, предназначенный для сокращения времени повторного анализа файлов за счёт хранения результатов предыдущего запуска линтера. Основная идея заключается в исключении повторной обработки тех файлов, содержимое и контекст которых не изменились с момента последнего запуска.
Кеш ESLint строится вокруг сопоставления входных данных анализа и результатов проверки. Входными данными выступают:
Результатом кеширования становится запись, позволяющая определить, требуется ли повторный анализ файла.
Кеш не является универсальным хранилищем результатов линтинга для всех сценариев, а работает в рамках конкретной конфигурации и набора правил.
По умолчанию ESLint использует файл .eslintcache,
размещаемый в корне проекта. Этот файл представляет собой
сериализованную структуру данных, содержащую:
Формат кеша бинарно-ориентированный (внутренний формат ESLint), оптимизированный для быстрого чтения и записи, а не для ручного редактирования.
Кеширование включается через CLI-флаг:
eslint . --cache
При включении ESLint начинает сохранять результаты анализа и повторно использовать их при следующих запусках.
Дополнительно может задаваться путь к файлу кеша:
eslint . --cache --cache-location ./tmp/eslint-cache
Это позволяет изолировать кеш между окружениями, ветками или CI-джобами.
При повторном запуске ESLint выполняет проверку валидности кеша на уровне каждого файла. Основные этапы:
Для каждого файла формируется хеш на основе его текущего содержимого. Любое изменение — даже минимальное (например, пробел или перенос строки) — приводит к изменению хеша.
Если файл присутствует в кеше, ESLint сравнивает:
Несовпадение любого элемента приводит к инвалидированию кеша для конкретного файла.
Конфигурация ESLint влияет на результат линтинга сильнее, чем содержимое файла. Изменения в:
.eslintrc.*;eslint.config.js (flat config);приводят к частичной или полной очистке кеша.
ESLint поддерживает различные стратегии формирования кеш-ключа, определяющие уровень точности сравнения.
Стратегия по умолчанию. Использует метаданные файловой системы:
Данная стратегия обеспечивает высокую скорость, но может быть менее точной в окружениях, где метаданные файловой системы ненадёжны (например, при синхронизации через сетевые диски).
Более строгий режим, основанный на полном хешировании содержимого файла. При этом учитываются только фактические данные файла без опоры на файловую систему.
eslint . --cache --cache-strategy content
Данный подход снижает риск ложных попаданий кеша, но увеличивает вычислительные затраты на его формирование.
Инвалидация кеша происходит при следующих условиях:
Любое изменение содержимого файла делает кеш-элемент недействительным.
Даже незначительные изменения в правилах или подключённых плагинах приводят к пересчёту всех затронутых файлов.
Обновление версии линтера может изменить поведение правил, что автоматически делает предыдущий кеш некорректным.
Флаги, влияющие на процесс анализа (--rule,
--env, --parser, --ext),
участвуют в формировании ключа кеша.
В монорепозиториях кеширование приобретает дополнительную сложность из-за наличия нескольких пакетов и конфигураций.
Особенности:
Рекомендуемая практика — разделение кеша по пакетам:
eslint packages/* --cache --cache-location packages/a/.eslintcache
Это снижает вероятность конфликтов между различными конфигурациями.
Плагины ESLint влияют на кеш не только через правила, но и через собственные процессоры и парсеры.
Особенности:
Таким образом, кеш ESLint чувствителен не только к исходному файлу, но и к цепочке его преобразований.
В CI-средах кеш используется для ускорения повторных запусков линтера между сборками.
Типовые подходы:
Кеш файл сохраняется как артефакт и восстанавливается в следующем запуске:
eslint . --cache --cache-location .cache/eslint
В CI часто линтируются только изменённые файлы, что усиливает эффективность кеша:
eslint . --cache --cache-strategy metadata
При параллельных джобах кеш может перезаписываться. Для предотвращения используются:
Кеширование снижает время повторного запуска, но добавляет накладные расходы:
Эффект кеша становится заметен при большом количестве файлов (сотни и тысячи). В небольших проектах выигрыш может быть минимальным или отсутствовать.
Несмотря на оптимизацию, кеш ESLint имеет ряд ограничений:
Также кеш не учитывает семантические изменения, если они не отражены в входных данных (например, внешние зависимости, используемые в кастомных правилах).
Кеширование автоматически обходится или становится неэффективным в случаях:
В таких сценариях ESLint выполняет полноценный анализ без повторного использования предыдущих результатов.
Новая система конфигурации ESLint (flat config) усиливает детерминированность кеша. Конфигурация становится более явной, что снижает количество скрытых зависимостей.
Особенности:
Однако динамические конструкции в конфиге (условные экспорты, вычисляемые правила) могут увеличивать нестабильность кеша.
Кеш ESLint функционирует как детерминированное отображение:
Эта модель позволяет балансировать между скоростью анализа и точностью результатов, сохраняя корректность линтинга при изменениях кода и инфраструктуры.