Внутренняя модель сборки Rollup основана на преобразовании графа модулей в набор оптимизированных выходных файлов, называемых чанками. Понимание механизма формирования чанков является ключевым для управления архитектурой бандла, оптимизации загрузки и контроля разделения кода.
Чанк представляет собой самостоятельную единицу вывода, содержащую один или несколько модулей, объединённых в единый исполняемый файл. В отличие от входного модуля, который задаёт точку старта графа зависимостей, чанк формируется Rollup автоматически в процессе анализа импортов и экспорта.
Каждый чанк обладает собственным набором:
Основная задача чанка — представлять минимально связную группу кода, которая может быть загружена и выполнена независимо при сохранении корректной работы связей между модулями.
Перед созданием чанков Rollup строит граф зависимостей. Каждый модуль
рассматривается как узел графа, а связи import и
export формируют рёбра.
На этом этапе выполняются следующие действия:
Именно структура графа определяет, какие модули будут объединены в один чанк, а какие разделятся.
Автоматическое разбиение на чанки происходит в момент формирования output. Rollup использует правила:
Если несколько входных точек используют одни и те же модули, Rollup стремится вынести их в отдельную общую единицу.
В процессе сборки выделяются два основных типа чанков:
Основной чанк формируется из входной точки и содержит:
Он является точкой запуска выполнения.
Вторичные чанки создаются автоматически в следующих случаях:
import())Такие чанки загружаются лениво и исполняются по мере необходимости.
Одним из ключевых механизмов создания чанков является динамический импорт. Конструкция:
import('./module.js')инструктирует Rollup о необходимости создать отдельный чанк для указанного модуля.
При обработке динамического импорта происходит:
Таким образом, динамический импорт напрямую управляет количеством чанков в итоговой сборке.
При наличии нескольких входных точек Rollup анализирует пересечение зависимостей. Если модуль используется в разных частях графа, он может быть вынесен в отдельный чанк.
Пример логики:
В этом случае модуль X становится отдельным shared-чанком.
Такое поведение снижает дублирование и уменьшает общий размер бандла.
Rollup использует несколько принципов группировки:
Модули, связанные только статическими импортами, стремятся объединяться в единый чанк.
Каждый динамический импорт формирует отдельную область разделения.
Одинаковые зависимости не копируются, а выносятся в общие чанки.
Каждый чанк должен сохранять семантику ES-модулей без конфликтов имён и побочных эффектов.
Имена чанков формируются на основе конфигурации output:
При использовании параметра output.chunkFileNames можно
управлять шаблоном именования, включая:
[name] — имя чанка[hash] — хеш содержимого[format] — формат выводаЭто позволяет контролировать структуру выходной директории.
Tree-shaking оказывает прямое влияние на состав чанков. Перед формированием чанков Rollup удаляет неиспользуемые экспортируемые сущности.
Последовательность обработки:
В результате размер каждого чанка уменьшается ещё до его создания как файла.
После разделения кода чанки не существуют изолированно. Они связаны системой импортов и runtime-механизмом Rollup.
Связи включают:
Это обеспечивает корректное выполнение даже при частичной загрузке приложения.
Избыточное количество чанков может ухудшить производительность из-за увеличения числа сетевых запросов. Rollup и разработчик могут влиять на этот процесс:
Баланс между количеством чанков и их размером является важной задачей оптимизации сборки.
При наличии нескольких entry points Rollup формирует отдельные графы, которые затем пересекаются через общие зависимости.
Процесс включает:
Такой подход позволяет строить многостраничные приложения с эффективным переиспользованием кода.
Каждый чанк работает в рамках runtime-среды Rollup, которая обеспечивает:
Runtime является связующим слоем между отдельными чанками и обеспечивает их совместимость.
Внутренняя логика Rollup сводится к последовательному процессу:
Эта модель обеспечивает предсказуемое и оптимизированное разбиение кода, позволяя управлять структурой сборки на уровне архитектуры приложения.