В процессе сборки Parcel активно использует локальное кэширование промежуточных результатов трансформации модулей. Для этого в корне проекта создаётся скрытая директория .parcel-cache, которая служит постоянным хранилищем вычисленных артефактов между запусками сборки.
Основная задача этой директории заключается в сокращении времени последующих сборок за счёт переиспользования уже обработанных ресурсов. Parcel стремится избегать повторного выполнения дорогих операций — парсинга, трансформации, транспиляции и оптимизации — если входные данные не изменились.
Внутреннее устройство директории не является частью публичного API и может изменяться между версиями Parcel, однако логически её содержимое можно разделить на несколько категорий.
Parcel хранит результаты обработки каждого модуля исходного кода. Это включает:
Каждый модуль идентифицируется через хеш зависимости, который учитывает:
Любое изменение этих факторов приводит к инвалидации соответствующего кэша.
Parcel строит и сохраняет граф зависимостей проекта. В .parcel-cache хранится:
Этот граф используется для инкрементальной пересборки: при изменении одного узла пересчитывается только затронутая подграфовая область.
Отдельный слой кэша отвечает за разрешение модулей:
Это снижает накладные расходы на повторное вычисление путей при каждой сборке.
Parcel поддерживает расширяемую систему плагинов. Для них также формируется изолированный кэш:
Каждый плагин получает собственный namespace внутри кэша, что предотвращает конфликты между различными этапами сборки.
Ключевая особенность .parcel-cache заключается в строгой системе инвалидации. Кэш считается валидным только при совпадении всех входных параметров.
Parcel использует content hashing, где итоговый ключ кэша формируется из совокупности всех влияющих факторов. Даже минимальное изменение входных данных приводит к генерации нового ключа.
Использование .parcel-cache позволяет реализовать инкрементальную модель сборки. При повторном запуске:
Это особенно критично для крупных проектов, где полная пересборка может занимать значительное время.
По умолчанию директория располагается в корне проекта:
project/
src/
dist/
.parcel-cache/Формат хранения бинарный и оптимизирован под быстрый доступ. Внутри используются:
Прямое редактирование файлов кэша не предусмотрено и может привести к неконсистентности сборки.
Удаление директории приводит к полной потере кэшированных данных. При следующем запуске сборки Parcel:
Это эквивалентно «холодному старту» сборки.
В большинстве случаев удаление используется для устранения:
Директория .parcel-cache обычно исключается из системы контроля версий. Причины:
Стандартная запись для .gitignore:
.parcel-cacheВ системах непрерывной интеграции кэш может существенно ускорять сборку. Однако важно учитывать корректную стратегию его сохранения.
Типовой подход:
Некорректное использование кэша в CI может приводить к:
Конфигурационные файлы напрямую влияют на ключи кэширования:
.parcelrcpackage.json (поля Parcel)Изменение любого параметра приводит к частичной или полной инвалидации кэша, даже если исходный код остаётся неизменным.
Parcel использует несколько уровней оптимизации кэша:
Это позволяет минимизировать диск I/O и ускорять повторные сборки даже в сложных монорепозиториях.
Некоторые типичные ситуации связаны с некорректным поведением кэша:
Несоответствие результата сборки
Аномально медленная пересборка
Различия между локальной и CI сборкой
Для диагностики применяются режимы:
Директория .parcel-cache является центральным элементом архитектуры сборщика. Она обеспечивает:
Parcel фактически рассматривает файловую систему кэша как продолжение внутреннего состояния компилятора между запусками процесса сборки.