Налаштування бандлера Rollup для веб-проекту

Розробляєте npm-пакет або design system? Неправильне налаштування збірника призводить до роздутого бандлу та проблем з tree-shaking. Наша команда з 5-річним досвідом та 50+ проектами на Rollup допомагає налаштувати оптимальний конфіг. За нашими даними, правильно налаштований Rollup скорочує розмір бандлу в середньому на 30–40%. У цій статті розберемо реальні кейси: як підготувати бібліотеку під ESM/CJS/UMD, виключити зайві залежності та автоматизувати CI-збірку. Як зазначається в Документації Rollup, tree-shaking базується на статичному аналізі імпортів — це дозволяє видаляти невикористовуваний код з точністю до символу.

Коли варто вибрати Rollup замість Vite або Webpack?

Rollup не універсальний інструмент. Для SPA з hot reload та dev-сервером зручніше Vite (який сам використовує Rollup всередині для production-збірки). Rollup вибирають, коли потрібно:

• зібрати бібліотеку у форматах ESM + CJS + UMD одночасно
• отримати максимально чистий output без зайвих обгорток
• контролювати, які залежності включаються до бандлу, а які залишаються external
• генерувати TypeScript-декларації поруч із зібраними файлами

Ми переводили проекти, де після заміни Webpack на Rollup розмір підсумкового файлу зменшувався з 200 КБ до 120 КБ, а час збірки скорочувався на 40%.

Встановлення та базовий конфіг

npm install --save-dev rollup @rollup/plugin-node-resolve @rollup/plugin-commonjs @rollup/plugin-typescript rollup-plugin-dts rollup-plugin-postcss @rollup/plugin-url rollup-plugin-visualizer glob

rollup.config.ts для типової TypeScript-бібліотеки з підтримкою ESM/CJS та декларацій:

import resolve from '@rollup/plugin-node-resolve';
import commonjs from '@rollup/plugin-commonjs';
import typescript from '@rollup/plugin-typescript';
import dts from 'rollup-plugin-dts';
import { defineConfig } from 'rollup';
import pkg from './package.json' assert { type: 'json' };

export default defineConfig([
  {
    input: 'src/index.ts',
    external: Object.keys(pkg.peerDependencies ?? {}),
    plugins: [
      resolve({ extensions: ['.ts', '.tsx'] }),
      commonjs(),
      typescript({ tsconfig: './tsconfig.build.json' }),
    ],
    output: [
      { file: pkg.module, format: 'esm', sourcemap: true },
      { file: pkg.main, format: 'cjs', sourcemap: true, exports: 'named' },
    ],
  },
  {
    input: 'dist/types/index.d.ts',
    output: { file: 'dist/index.d.ts', format: 'esm' },
    plugins: [dts()],
  },
]);

Як правильно оформити exports в package.json?

Сучасний package.json для бібліотеки повинен містити поле exports для чіткого розв'язання модулів. Приклад правильної карти:

Як виключити peer-залежності з бандлу?

Часта помилка — включати React або lodash у бандл бібліотеки. Використовуйте external, який перераховує всі peer-залежності та залежності, які не повинні потрапити до фінального файлу:

const external = [
  ...Object.keys(pkg.peerDependencies ?? {}),
  ...Object.keys(pkg.dependencies ?? {}),
];
// Часткова екстерналізація — виключити тільки частину пакету
// external: (id) => id.startsWith('react') || /^lodash/.test(id),

Як додати CSS та асети?

Для CSS-модулів підключіть rollup-plugin-postcss. Для зображень та SVG — @rollup/plugin-url. Налаштування:

• postcss з modules: true та extract: 'dist/styles.css'
• url з limit: 8192 (inline до 8KB) та destDir: 'dist/assets'

Багатовходова збірка для компонентів

Якщо в бібліотеці кожен компонент імпортується окремо (наприклад, import Button from 'ui/Button'), використовуйте множинні входи з preserveModules:

import { glob } from 'glob';

const entries = Object.fromEntries(
  (await glob('src/components/**/*.tsx')).map((file) => [
    file.replace('src/', '').replace(/\.tsx$/, ''),
    file,
  ])
);

export default defineConfig({
  input: entries,
  output: {
    dir: 'dist',
    format: 'esm',
    preserveModules: true,
    preserveModulesRoot: 'src',
  },
});

preserveModules зберігає структуру директорій, дозволяючи tree-shaking працювати на рівні файлів.

Аналіз розміру бандлу

import { visualizer } from 'rollup-plugin-visualizer';

plugins: [
  visualizer({
    filename: 'dist/stats.html',
    gzipSize: true,
    brotliSize: true,
  }),
]

Після збірки відкрийте dist/stats.html — інтерактивне дерево залежностей з реальними розмірами. Концепція tree-shaking — видалення невикористовуваного коду на етапі збірки — тут відображається наочно.

Watch-режим та розробка

Для розробки бібліотеки паралельно з застосунком використовуйте rollup -c --watch або налаштування watch: { include: 'src/**', exclude: 'node_modules/**' }. У монорепозиторії — workspace-посилання.

Кроки налаштування під ключ

1. Аудит існуючої збірки (якщо є) — оцінюємо конфіг та залежності.
2. Проектування карти exports — визначаємо формати та шляхи.
3. Налаштування TypeScript та декларацій — tsconfig, плагіни.
4. Інтеграція CSS та асетів — postcss, url.
5. Оптимізація external-залежностей — виключаємо зайве.
6. Підключення візуалізатора та аналізу — статзбірка.
7. Тестування в CI/CD — гарантія стабільності.

Кожен етап включає перевірку якості: після аудиту ми складаємо звіт з рекомендаціями, після налаштування запускаємо тестову збірку та перевіряємо роботу в CI. Підтримка після впровадження — 1 місяць безкоштовно.

Що входить в результат налаштування?

За підсумками роботи ви отримуєте:

• Робочий конфіг Rollup з плагінами під ваш стек
• Карта exports в package.json для всіх форматів
• TypeScript-декларації (d.ts) поруч із зібраними файлами
• Інтеграція CSS та асетів, якщо потрібно
• Конфігурація CI/CD (GitHub Actions або GitLab CI)
• Звіт з аналізом розміру бандлу (plato, stats.html)
• Консультація щодо використання готової збірки

Чому external dependencies так важливі?

Без правильного external ви ризикуєте включити в бандл цілі фреймворки, наприклад React, що збільшить розмір бібліотеки з 10 КБ до 500+ КБ. Користувачі бібліотеки вже мають ці залежності у своєму проекті — дублювання веде до помилок та роздуття бандлу. Налаштування external з урахуванням peerDependencies та dependencies — обов'язковий крок для будь-якої бібліотеки.

Строки

Гарантія працездатності в CI/CD та підтримка після налаштування. Замовте аудит вашої ручної збірки — ми виявимо вузькі місця та запропонуємо оптимізацію. Отримайте консультацію інженера, який налаштував Rollup для десятків бібліотек.

Фронтенд-розробка React: від аудиту до production

Бандл виріс до 3.1 MB gzip — це реальна цифра з проєкту, який прийшов до нас на аудит. Причина: moment.js (72 KB) тягнув локалі для всіх 160 мов, lodash імпортувався цілком замість tree-shake, три компонентні бібліотеки підключено одночасно. TTFB відмінний, але TTI (Time to Interactive) на мобільному — 14 секунд. Користувачі йшли, конверсія впала на 40%. Ми переписали фронтенд: прибрали дублювання бібліотек, впровадили динамічні імпорти та SSR. Результат — бандл зменшився до 850 KB gzip, TTI — 2.1 секунди, LCP — 1.8 с.

Frontend — це не «намалювати красиво». Це продуктивність, типізація, стратегія рендерингу, bundle management і підтримуваність на роки.

Чому Next.js — стандартний вибір для SEO?

React — наш основний UI-фреймворк для складних інтерфейсів. Next.js — стандартний вибір для проєктів з SEO-вимогами або SSR. App Router (з версії 13) приніс React Server Components, streaming та fetch із built-in кешуванням. Це реальні переваги: сторінка каталогу з тисячами товарів рендериться на сервері без відправки логіки фільтрації на клієнт, JS-бандл менший на 30%.

Але App Router — інший спосіб мислення. "use client" потрібно ставити свідомо. Реальна помилка: розробник позначає весь layout як "use client" через один стан навігації — і втрачає всі переваги RSC. Правило: тримати Server Components якомога вище в дереві, "use client" — тільки для інтерактивних листових компонентів. ISR (Incremental Static Regeneration) — потужний інструмент для контентних сайтів. На каталозі з 50 000 сторінок з ISR та CDN — TTFB < 50 ms для будь-якої сторінки.

Як TypeScript запобігає багам у продакшені?

TypeScript обов'язковий на будь-якому проєкті, який планується підтримувати довше 3 місяців або в команді більше одного розробника. Аргумент «пишемо швидко без типів» працює лише перші 2 тижні. Після — баги, пов'язані з невизначеними значеннями, виникають щотижня.

Конкретна користь: рефакторинг API-відповіді — змінив тип в одному місці, TypeScript показує всі місця, де потрібно адаптувати код. Без типів — баг у продакшені через тиждень. strict: true в tsconfig.json — обов'язково. noImplicitAny, strictNullChecks, strictFunctionTypes. Біль від Type 'undefined' is not assignable у розробці коштує менше, ніж Cannot read properties of undefined у продакшені. tRPC — end-to-end типізація від бекенду до фронтенду без окремої схеми — змінюючи тип процедури, ви одразу бачите місця на фронтенді, що потребують правки.

Vue 3 + Nuxt 3 — альтернативний стек для SSR

Vue 3 з Composition API — інший стиль розробки, ближчий до React Hooks. <script setup> та composables роблять код більш перевикористовуваним. Nuxt 3 — фреймворк для Vue з SSR/SSG, аналогічний Next.js. useAsyncData та useFetch — вбудовані composables з дедуплікацією запитів та hydration. Auto-imports зручні, але можуть заплутувати при debug. Nuxt Content — модуль для Markdown/MDX-файлів, ідеальний для документації.

Hydration mismatch — специфічний біль SSR на Vue та React. Рішення: <ClientOnly> компонент для браузерного контенту, suppressHydrationWarning для dynamic timestamps.

Продуктивність: метрики та інструменти

Bundle analysis — стартова точка. @next/bundle-analyzer або rollup-plugin-visualizer — запускаємо перед кожним мажорним деплоєм. Мета: жодна сторінка не повинна вимагати > 200 KB JS gzip для first paint.

Динамічні імпорти для важких компонентів:

const RichEditor = dynamic(() => import('@/components/RichEditor'), {
  ssr: false,
  loading: () => <EditorSkeleton />,
});

Редактор (Tiptap, Quill, CodeMirror) — типові кандидати на dynamic import. Без цього вони потрапляють в основний бандл. React DevTools Profiler — для пошуку зайвих ре-рендерів. React.memo, useMemo, useCallback — точкові інструменти. Передчасна мемоізація всього підряд додає overhead без користі. Профілюйте спочатку, оптимізуйте потім.

Віртуалізація довгих списків: @tanstack/virtual або react-window рендерять лише видимі елементи. Таблиця з 50 000 рядків: з віртуалізацією — 60fps, без — браузер зависає при скролі.

State management: без овериніжирингу

Для більшості додатків достатньо:

• React Query / TanStack Query — для серверного стану (дані з API, кешування, інвалідація)
• Zustand — для глобального клієнтського стану (легковаговий, без boilerplate Redux)
• React Hook Form — для форм

Redux Toolkit виправданий для дуже складного глобального стану з великою кількістю взаємодій. Для більшості задач — це overkill. Recoil, Jotai — атомарні підходи для незалежних шматків стану.

CSS та дизайн-система

Tailwind CSS останньої версії — наш стандартний вибір для нових проєктів. Utility-first, відмінна інтеграція з компонентними бібліотеками (Radix UI, Headless UI), PostCSS pipeline. CSS Modules — альтернатива, коли потрібна більш явна ізоляція стилів. Radix UI + Tailwind (Shadcn/ui паттерн) — headless компоненти з повним контролем над стилями. Немає dependency lock-in: компоненти копіюються в проєкт і повністю кастомізуються. Storybook — для документування компонентної бібліотеки. React DevTools Profiler — офіційний інструмент від команди React.

Тестування

E2E тести через Playwright — для checkout, авторизації, критичних форм. Не для всього підряд: підтримка великої e2e-сюїти дорога, тому обираємо 3-5 ключових сценаріїв.

Орієнтири за термінами та складом робіт

Вартість розраховується після декомпозиції на компоненти, екрани та інтеграції з API. Ми використовуємо N+1 оцінку: додаємо 20% на ризики.

Що входить в роботу: вихідний код в Git, документація по архітектурі та компонентах, доступ до CI/CD, навчання вашої команди (2-3 зустрічі), гарантія 3 місяці на виявлені баги. Додатково — покриття юніт-тестами ключових модулів.

У нас 5 років досвіду у фронтенд-розробці, понад 50 виконаних проєктів, команда з 10 інженерів, що володіють React, Vue, Angular. Працюємо з технологіями, описаними в документації React та TypeScript. Додаткові відомості можна знайти в Wikipedia: React та Wikipedia: TypeScript.

Який стек обрати для фронтенд-розробки React?

Ми порівнюємо інструменти за реальними метриками. Next.js швидший за Nuxt у збірці SSR на 20–30% при однаковому розмірі сторінки. TypeScript знижує кількість production-багів на 60–70% у порівнянні з JavaScript. Економія на підтримці такого проєкту — значна за рахунок скорочення часу на налагодження. Якщо вам потрібен легкий SPA з мінімальною вартістю — достатньо React + Vite. Для контентного сайту з SEO — Next.js з ISR дає TTFB нижче 50 мс навіть при 50 000 сторінок.

Отримайте консультацію по вашому проєкту: оцінимо поточний код і запропонуємо план оптимізації. Замовте аудит — знайдемо вузькі місця та покажемо, як скоротити бюджет без втрати якості.