Що таке bundler і навіщо він збирає ваш фронтенд у меншу купу файлів

Hook

Bundler — це тихий працівник фронтенду. Він бере багато дрібних модулів, картинок і стилів та перетворює їх у результат, який браузер може швидко завантажити. Якщо його не розуміти, легко отримати повільний сайт і дивні помилки після релізу.

Problem / Context

У сучасному JavaScript проєкті код уже давно не живе в одному файлі. Є модулі, сторонні пакети, стилі, картинки, а інколи ще й різні варіанти для dev і production. Браузер може читати модулі напряму, але це не вирішує все: треба зібрати залежності, підкласти ресурси в правильні місця і зробити output придатним для продакшну.

Саме тут з’являється bundler. Він проходить по зв’язках між файлами, будує карту залежностей і вирішує, що покласти в один bundle, а що краще винести окремо. Для розробника це виглядає як одна команда. Насправді під капотом — купа дрібної, але важливої роботи.

Why it matters

Якщо bundler налаштований нормально, ти отримуєш:

• швидше перше завантаження;
• менше зайвого коду в браузері;
• зрозумілий результат для CI і деплою;
• кращий кеш: змінюється одна частина, а не весь сайт.

Якщо ні — користувачі тягнуть зайві мегабайти, сторінка відкривається повільно, а зміна одного маленького файлу ламає великий шматок збірки.

Illustration

На схемі зліва — вхідні файли, посередині — bundler, справа — готові файли для браузера. Ідея проста: не тягнути все одразу, а віддати лише те, що треба зараз.

How to do it

1. Подивись, що саме запускається

Відкрий package.json і знайди скрипт build. Часто він викликає vite build, webpack, rollup або іншу збірку.

{
  "scripts": {
    "dev": "vite",
    "build": "vite build",
    "preview": "vite preview"
  }
}

Тут npm run build запускає не магію, а звичайний інструмент збірки. Якщо в проєкті інший стек, логіка та сама: подивись, який файл входу він читає і куди складає output.

2. Зрозумій, де є межі bundle

Bundler не зобов’язаний пакувати все в один великий файл. Частину коду краще віддати окремо через code splitting, щоб важкі екрани завантажувались тільки тоді, коли вони потрібні.

button.addEventListener("click", async () => {
  const { openSettings } = await import("./settings.js");
  openSettings();
});

У такому варіанті модуль settings.js не потрапляє в перший bundle цілком. Він підтягується лише при потребі. Це корисно для великих адмінок, кабінетів і сторінок з рідкісними діями.

3. Прибери зайвий код

Якщо проєкт написаний на сучасних модулях, bundler може прибрати невикористаний код через tree shaking. Але це працює лише тоді, коли залежності і сам проєкт написані акуратно. Якщо тягнути цілу бібліотеку заради однієї функції, користувач отримає зайвий баласт.

4. Перевір результат як користувач

Після build недостатньо просто побачити папку dist або build. Відкрий результат через preview або локальний сервер. Подивись, чи працюють маршрути, стилі, картинки і lazy-loaded частини. Саме тут вилізають криві шляхи, не ті base URL і сюрпризи з assets.

5. Порівняй до і після

Якщо ти змінив конфіг, подивись на розмір output і на кількість файлів. Менший bundle не завжди означає кращий результат, але дуже великий bundle майже завжди означає, що є що спростити.

Anti-patterns

• зводити весь проєкт до одного гігантського bundle;
• тягнути важкі бібліотеки заради однієї дрібної фічі;
• міняти конфіг bundler без перевірки preview;
• плутати build і deploy;
• ігнорувати warnings, які потім перетворюються на баги;
• додавати code splitting всюди без причини — дрібний шматок теж має свою ціну.

Conclusion / Action plan

Bundler — це не окремий “чарівний” крок, а частина build-процесу, яка вирішує, як саме ваш код потрапить у браузер.

Що робити далі:

1. знайти, який bundler стоїть у проєкті;
2. подивитися, де формується bundle і які частини можна розділити;
3. запустити build і відкрити результат у preview;
4. прибрати зайве і перевірити, чи не зламався output;
5. тримати build у CI, щоб сюрпризи ловити до релізу.

Офіційні джерела:

• https://vite.dev/guide/features.html#build
• https://webpack.js.org/concepts/
• https://rollupjs.org/configuration-options/#output-manualchunks