Одним из ключевых механизмов повышения производительности сборки в Parcel является система кэширования. Во время работы Parcel анализирует исходный код, выполняет трансформации, разрешает зависимости, оптимизирует ресурсы и формирует выходные файлы. Каждый из этих этапов требует вычислительных затрат.
При повторных запусках сборщика выполнение одних и тех же операций становится избыточным. Для устранения этой проблемы Parcel сохраняет промежуточные результаты в специальном кэше и повторно использует их при необходимости.
Совместное использование кэша позволяет нескольким процессам, сборочным средам или участникам команды использовать уже подготовленные результаты, сокращая время компиляции и уменьшая нагрузку на вычислительные ресурсы.
При выполнении сборки Parcel создаёт каталог кэша, в котором сохраняются:
Если исходный файл не изменился, Parcel извлекает результат из кэша вместо повторной обработки.
Упрощённая схема работы выглядит следующим образом:
Такой подход значительно ускоряет повторные сборки проектов среднего и большого размера.
По умолчанию Parcel создаёт директорию:
.parcel-cacheСтруктура проекта может выглядеть следующим образом:
project/
├── src/
├── dist/
├── package.json
└── .parcel-cache/Содержимое каталога предназначено исключительно для внутренних механизмов Parcel.
Файлы внутри кэша:
В небольших проектах локального кэша обычно достаточно. Однако в крупных системах возникают дополнительные требования.
В команде десятки разработчиков могут ежедневно выполнять одинаковые операции сборки.
Без общего кэша каждый участник заново выполняет:
При наличии общего кэша уже подготовленные результаты становятся доступны другим участникам.
Системы непрерывной интеграции запускают сборку при каждом коммите.
Например:
Commit → Build → Test → DeployЕсли кэш сохраняется между сборками, повторная обработка неизменившихся файлов не требуется.
В результате:
Монорепозиторий может содержать десятки приложений и библиотек:
repo/
├── apps/
│ ├── admin
│ ├── store
│ └── mobile
└── packages/
├── ui
├── utils
└── apiМногие пакеты используются одновременно несколькими приложениями.
Совместное использование кэша позволяет избежать многократной обработки одинаковых модулей.
Parcel позволяет указать собственный каталог хранения кэша.
Пример:
parcel build src/index.html --cache-dir .cacheПосле выполнения команды структура проекта изменится:
project/
├── src/
├── dist/
└── .cache/Подобный подход используется при:
В некоторых инфраструктурах несколько процессов могут использовать один каталог кэша.
Например:
/shared-cache/parcelЗапуск сборки:
parcel build src/index.html --cache-dir /shared-cache/parcelПреимущества:
Однако необходимо учитывать вопросы синхронизации и доступа к файловой системе.
Практически все современные CI-системы поддерживают сохранение каталогов между запусками.
Пример логики работы:
1. Восстановить кэш
2. Установить зависимости
3. Выполнить сборку
4. Сохранить обновлённый кэшСхема:
Previous Build
│
▼
Restore Cache
│
▼
Parcel Build
│
▼
Save CacheВ результате повторные сборки выполняются значительно быстрее.
Parcel учитывает состояние зависимостей проекта.
Если изменяются:
package-lock.jsonили
yarn.lockчасть кэша может стать недействительной.
Причина заключается в том, что обновление пакетов способно изменить:
Поэтому после обновления библиотек часть данных автоматически пересчитывается.
Инвалидация представляет собой процесс признания кэшированных данных устаревшими.
Parcel автоматически отслеживает изменения:
Если обнаружено изменение, соответствующие записи удаляются или пересчитываются.
Например:
src/app.js изменён
↓
запись в кэше устарела
↓
выполняется повторная обработка
↓
результат сохраняется зановоТакой механизм гарантирует корректность итоговой сборки.
Иногда требуется полное удаление кэшированных данных.
Наиболее простой способ:
rm -rf .parcel-cacheПосле удаления следующий запуск выполнит полную сборку.
Причины очистки:
Для диагностических целей кэш можно отключить.
Пример:
parcel build src/index.html --no-cacheВ этом режиме:
Подобный режим полезен при поиске трудно воспроизводимых ошибок.
В крупных организациях применяется удалённый кэш.
Схема работы:
Developer
│
▼
Remote Cache Server
│
▼
Stored Build ArtifactsПри сборке выполняются действия:
Подобный подход широко используется в больших монорепозиториях.
Parcel активно использует многопоточность.
Во время работы могут одновременно выполняться:
Совместный кэш позволяет этим процессам обмениваться результатами без дублирования вычислений.
Схема:
Process A ─┐
├─► Shared Cache
Process B ─┤
├─► Shared Cache
Process C ─┘Это особенно важно для крупных проектов с большим количеством ресурсов.
Время сборки обычно делится на два сценария.
Кэш отсутствует:
Build Time = Максимальное времяВыполняются все этапы обработки.
Кэш уже заполнен:
Build Time = Минимальное времяПовторно обрабатываются только изменённые файлы.
В крупных приложениях разница может составлять десятки секунд или даже минуты.
Наиболее эффективная оптимизация для большинства проектов.
Преимущества:
Каталог:
.parcel-cacheобычно добавляется в .gitignore:
.parcel-cacheПричины:
Скорость чтения и записи напрямую влияет на эффективность кэша.
Предпочтительно использовать:
При длительной работе проекта объём кэша может существенно увеличиваться.
Регулярная очистка помогает:
Shared Cache
┌──────────┐
│ Artifacts│
└────┬─────┘
│
┌───────────────┼───────────────┐
│ │ │
▼ ▼ ▼
Developer A Developer B CI Server
│ │ │
└───────────────┼───────────────┘
▼
Parcel BuildВ такой архитектуре результаты сборки переиспользуются всеми участниками процесса, что позволяет существенно сократить время компиляции, повысить эффективность CI/CD-инфраструктуры и уменьшить количество повторных вычислений при работе с крупными JavaScript-проектами на базе Parcel.