Когда работаешь над библиотекой, хочется получить исходник, который легко подключается, быстро загружается и понятен пользователю. Rollup позволяет именно это: минимальный и модульный сборочный инструмент, ориентированный на библиотеки и оптимизацию конечного кода. В этой статье разберём, почему он часто оказывается лучшим выбором, как собрать несколько форматов вывода, какие плагины действительно полезны и какие ошибки стоят избегать.

Почему Rollup часто выбирают для библиотек

Главная сильная сторона Rollup — ориентация на стандарты ES-модулей и эффективный tree shaking. Он анализирует импорт-экспорт на уровне модулей и удаляет неиспользуемый код, что даёт заметное снижение размера итогового бандла без дополнительных ухищрений.

Кроме того, конфигурация Rollup обычно короче и понятнее, чем у крупных сборщиков: вы задаёте вход, выход и список плагинов. Для библиотек это важно — вам не нужна сложная система для приложения с множеством точек входа, а нужна предсказуемая и стабильная сборка.

Ключевые понятия, которые стоит знать

Entry — точка входа вашей библиотеки. Output — форматы и связанные параметры: ES module (es), CommonJS (cjs), UMD или IIFE для браузерных сборок. Правильный выбор форматов определяет, как пользователи смогут подключать пакет.

External — список зависимостей, которые не должны попадать в бандл. Чётко помечая внешние пакеты (например, React или lodash), вы уменьшаете размер сборки и избегаете дублирования при совместном использовании у потребителя.

Форматы вывода и их назначение

ES module (esm) нужен для современных сборщиков и браузеров с поддержкой модулей — он делает возможным дальнейшее tree shaking у потребителя. CommonJS остаётся стандартом для Node-пакетов и старых окружений.

UMD и IIFE — варианты для использования прямо в браузере через тег script. UMD удобен тем, что работает и в Node, и в браузере, но обычно получается больше по размеру. В большинстве случаев достаточно сочетания esm + cjs.

Быстрый старт: базовая конфигурация

Установите rollup и нужные плагины через npm или yarn. Типичный набор для библиотеки включает минимум: @rollup/plugin-node-resolve и @rollup/plugin-commonjs, плюс плагины для транспиляции или минификации по необходимости.

Вот простая конфигурация, которую я часто использую как отправную точку:

import resolve from '@rollup/plugin-node-resolve';
import commonjs from '@rollup/plugin-commonjs';
import { terser } from 'rollup-plugin-terser';

export default {
  input: 'src/index.js',
  external: ['react'],
  output: [
    { file: 'dist/index.cjs.js', format: 'cjs', sourcemap: true },
    { file: 'dist/index.esm.js', format: 'es', sourcemap: true }
  ],
  plugins: [resolve(), commonjs(), terser()]
};

Эта конфигурация создаст два формата и заодно минифицирует итог для продакшена. Обратите внимание на параметр external — он исключает React из бандла.

Плагины: какие действительно понадобятся

Список полезных плагинов невелик, но каждый решает конкретную задачу. Ниже — краткий набор с пояснениями.

  • @rollup/plugin-node-resolve — разрешение модулей из node_modules.
  • @rollup/plugin-commonjs — преобразование CommonJS в ES-модули для импорта.
  • rollup-plugin-terser — минификация финального кода.
  • @rollup/plugin-typescript или @rollup/plugin-babel — если нужна транспиляция.
  • @rollup/plugin-replace — подмена переменных окружения, полезно для NODE_ENV.

Подбирайте плагины по потребности: лишние трансформации увеличат время сборки и усложнят отладку.

Сравнение с другими инструментами

Иногда выбор между Rollup, Webpack и esbuild кажется сложным. Таблица ниже помогает быстро увидеть различия в контексте библиотек.

Критерий Rollup Webpack esbuild
Tree shaking Отличный (ориентирован на ES) Хороший, но сложнее настроить Хороший, очень быстрый
Размер бандла Часто минимальный Может быть больше без оптимизаций Компактен, но с ограничениями по плагинам
Скорость сборки Умеренная Медленнее на крупных проектах Очень высокая

Выбор зависит от приоритетов: если критичен размер и чистота модулей — Rollup. Если важна гибкость для приложения с множеством ресурсов — Webpack. Если нужна очень быстрая сборка и вам подходят ограничения — esbuild.

Типичные ошибки и как их избежать

Самая частая ошибка — не пометить external зависимости, из-за чего в бандл попадают большие пакеты. Это увеличивает размер и может привести к конфликтам у потребителя библиотеки.

Другая ошибка — полагаться на трансформаторы по умолчанию и забывать про sourcemap. Без карт отладка минифицированного кода превращается в пытку и усложняет поддержку.

Проблемы с пакетированием CommonJS

Когда вы импортируете пакеты в CommonJS формате, иногда требуется точная настройка commonjs-плагина: перечисление имен, включение конкретных путей или указание namedExports. Это редкость, но о ней стоит помнить при сборке популярных зависимостей.

Если библиотека публикуется в npm, проверьте, что package.json содержит корректные поля «main» и «module». Неправильные пути приводят к тому, что потребители будут импортировать не тот файл.

Мой опыт: как я уменьшил библиотеку в три раза

Работая над своим небольшим UI-утилитом, я столкнулся с тем, что сборка весила больше 100 КБ. Анализ показал два источника: ненужные полифилы и включённые большие утилиты из lodash.

Я пометил lodash как external, заменил отдельные функции на собственные минимальные реализации и перешёл на именованные экспорты там, где это возможно. После этого и включения terser размер упал примерно в три раза, а потребители получили более понятный пакет.

Практические приёмы, которые сработали

Всегда начинайте с анализа бандла: tools вроде rollup-plugin-visualizer или source-map-explorer показывают, что именно занимает место. Это даёт конкретное направление для оптимизации.

Ещё один ход — публиковать несколько версий: esm для современных сборщиков и cjs для совместимости. Это даёт максимальную гибкость потребителю вашей библиотеки и не мешает оптимизировать размер.

Советы по публикации и совместимости

В package.json укажите поля «main» для CommonJS и «module» для ES-модулей. При возможности добавьте поле «types» для TypeScript-определений. Это облегчает жизнь пользователям и улучшает интеграцию с инструментами.

Публикуйте с sourcemap в отдельном файле, чтобы пользователи могли отлаживать код, а одновременно не нагружать основной файл. Gitignore для артефактов сборки сохраняет репозиторий чистым.

Когда Rollup может не подойти

Если ваш проект — крупное SPA с множеством точек входа, статических ресурсов и сложным код-сплиттингом, Rollup перестаёт быть очевидным выбором. Для таких задач Webpack или Vite/webpack-подобные решения дают больше инструментов «из коробки».

Также, если вам критична максимальная скорость сборки в режиме разработки, имеет смысл рассмотреть esbuild или SWC в связке с плагинами для соответствующих задач.

Rollup остаётся отличным выбором, когда вам нужна чистая, компактная библиотека с корректной поддержкой модулей и минимальной суммой неожиданностей для пользователя. Попробуйте начать с простой конфигурации, постепенно добавляя плагины по мере реальной необходимости, и анализируйте результат; эти простые шаги часто дают самый заметный выигрыш по размеру и поддерживаемости.