Сборка библиотеки и сборка приложения решают принципиально разные задачи, несмотря на использование схожих инструментов и конфигураций сборщиков. В контексте Rollup это различие проявляется особенно явно, поскольку инструмент изначально ориентирован на создание библиотек с максимально чистым и предсказуемым итоговым бандлом.
Сборка приложения ориентирована на выполнение конкретной бизнес-логики в рамках одного окружения. Итоговый бандл обычно обслуживает единственный продукт, тесно связан с инфраструктурой проекта и предполагает полный контроль над зависимостями и средой исполнения.
Сборка библиотеки направлена на повторное использование кода в различных проектах. Это накладывает ограничения на структуру выходного кода, формат модулей и степень связанности с внешними зависимостями. Библиотека должна быть максимально нейтральной по отношению к окружению, в котором она будет использоваться.
В приложении зависимости, как правило, включаются в итоговый бандл. Это упрощает деплой и гарантирует, что нужные версии библиотек будут поставляться вместе с кодом.
В библиотечной сборке ключевую роль играет механизм external в Rollup. Он позволяет исключить зависимости из бандла и оставить их для разрешения в проекте-потребителе. Это особенно важно для:
Типичная ошибка при сборке библиотек — включение всех зависимостей внутрь пакета. Это приводит к дублированию кода и конфликтам версий у потребителей.
Приложения чаще всего собираются в один формат, ориентированный на браузер или конкретную платформу. На практике это может быть ESM-бандл или IIFE-скрипт.
Библиотеки почти всегда требуют мультиформатной сборки:
Rollup позволяет формировать несколько output-конфигураций, каждая из которых должна учитывать особенности экспорта. Например, ESM сохраняет статическую структуру импортов, тогда как UMD требует глобального имени библиотеки.
В приложениях внутренние модули не предназначены для повторного использования. Поэтому структура экспорта не является важным архитектурным контрактом.
В библиотеках публичное API становится центральным элементом архитектуры. Rollup в этом контексте часто используется вместе с:
Особое значение имеет сохранение предсказуемой структуры экспортов. Любое изменение публичного API рассматривается как breaking change.
В приложениях tree-shaking часто вторичен, так как конечный бандл включает практически всю кодовую базу.
В библиотеках tree-shaking является критическим свойством. Rollup использует статический анализ импортов, что позволяет удалять неиспользуемый код, но только при соблюдении определённых условий:
Библиотечный код должен быть написан с учётом максимально «чистой» структуры модулей, где каждый экспорт не вызывает скрытых изменений состояния.
Приложения активно используют code splitting для оптимизации загрузки. Rollup в этом случае генерирует чанки, разделяя приложение по маршрутам или динамическим импортам.
Для библиотек code splitting, как правило, нежелателен. Итоговый пакет должен быть компактным и предсказуемым. В большинстве случаев используется:
Фрагментация библиотеки на множество чанков усложняет интеграцию и увеличивает накладные расходы у потребителя.
В приложениях зависимости обычно фиксируются внутри сборки, а версия контролируется через lock-файлы.
В библиотеках ключевую роль играют peerDependencies. Они определяют, что конкретные зависимости должны предоставляться окружением. Rollup-конфигурация должна учитывать это через external, иначе возникает риск:
Правильное разделение dependencies и peerDependencies становится архитектурным контрактом библиотеки.
При сборке библиотек в формате UMD требуется явное определение глобальных переменных. Rollup позволяет задать mapping внешних зависимостей через globals, чтобы обеспечить корректную работу в браузере без модульной системы.
В приложениях такая необходимость практически отсутствует, так как окружение заранее известно (например, Vite, Webpack или Node runtime).
В приложениях минификация направлена на уменьшение размера финального бандла и ускорение загрузки. Часто применяется агрессивное сжатие, включая удаление дебаг-логики.
В библиотеках подход более аккуратный:
Приложения допускают наличие глобального состояния и побочных эффектов, так как они управляются в рамках одного проекта.
В библиотеках побочные эффекты становятся критической проблемой. Rollup опирается на декларативную модель модулей, где:
Это влияет на способность библиотеки участвовать в tree-shaking и корректно комбинироваться с другими пакетами.
Конфигурация сборки приложения обычно проще:
Библиотечная конфигурация значительно сложнее и часто включает:
Дополнительно могут использоваться плагины для очистки кода, генерации деклараций и анализа размера бандла.
В приложениях версия бандла не является публичным контрактом — важна только текущая поставка.
В библиотеках версия становится частью API-контракта. Сборка должна учитывать:
Rollup в этом контексте выступает инструментом, обеспечивающим воспроизводимость артефакта, а не просто упаковку кода.
Различие между сборкой библиотеки и приложения в Rollup выражается не только в конфигурации, но и в философии:
Rollup в библиотечной сборке используется как инструмент строгой модульности, где важнее предсказуемость API и чистота зависимостей, чем агрессивная оптимизация под один конкретный сценарий выполнения.