Модуль 38

Збірка та production build

Ось готовий урок, написаний у стилі лекцій CS50. Уяви, що я стою на сцені в чорній футболці, активно жестикулюю і звертаюся до тебе.

🎓 Урок: Збірка та Production Build

(або "Як перетворити ваш код на готовий продукт")

1. 🔥 Вступ: Проблема та мотивація

Уявіть ситуацію. Ви працюєте над крутим веб-додатком. Ви — справжній шеф-кухар на своїй "кухні" розробки. У вас є: * Окремі файли для стилів (header.css, footer.css, button.css). * Купа JavaScript-модулів (один логінить користувача, інший малює графіки, третій валідує форми). * Можливо, ви навіть використовуєте TypeScript або SCSS.

На вашому потужному ноутбуці все працює ідеально. Але тут виникає питання: чи можете ви просто взяти ці 500 файлів і "закинути" їх на сервер користувачу?

(Пауза).

Звісно, ви можете. Але уявіть, що ви замовили піцу, а кур’єр привозить вам: окремо мішок борошна, окремо помідори, сир шматком і сире тісто. Він каже: "Ну, це ж піца, просто збери її сам у себе в духовці".

Браузер вашого користувача — це клієнт, який хоче готову піцу, а не інгредієнти.

Проблеми "сирого" коду: 1. Швидкість: Браузеру доведеться робити 500 запитів до сервера, щоб завантажити кожен маленький файл. Це вб'є продуктивність. 2. Сумісність: Браузери не розуміють TypeScript. Вони не розуміють SCSS. Старі браузери можуть не розуміти нові фішки JavaScript. 3. Безпека та розмір: Ваш код містить коментарі, пробіли, відступи — це зручно для вас, але зайвий вантаж для мережі.

Тож нам потрібен процес, який перетворить наш "творчий безлад" (Development) на оптимізований, компактний "продукт" (Production). Цей процес і називається Build (Збірка).

2. 🧠 Теоретична база (Що там "під капотом"?)

Давайте зазирнемо всередину "чорної скриньки", яку ми називаємо Bundler (збирач). Найпопулярніші сьогодні — це Vite, Webpack, Parcel.

Що саме вони роблять? Уявіть собі конвеєр на заводі.

1. Bundling (Об’єднання)

Збирач бере ваші 100 файлів і зшиває їх у кілька великих "пакунків" (bundles). * Аналогія: Замість того, щоб нести 50 окремих аркушів паперу, ви скріплюєте їх у одну зручну брошуру. * Чому? Один великий файл завантажується швидше, ніж 100 маленьких.

2. Transpilation (Транспіляція)

Це переклад. Ваш код може бути написаний на суперсучасному JS або TypeScript. Збирач (часто за допомогою Babel) перекладає це на "стандартний" JavaScript, який зрозуміє навіть старенький iPhone вашої бабусі. * Аналогія: Ви пишете наукову статтю академічною мовою, а збирач перекладає її простою мовою для широкого загалу.

3. Minification (Мініфікація)

Це видалення всього зайвого. * Видаляються пробіли, переноси рядків, коментарі. * Довгі назви змінних (const userIsLoggedIn = true) замінюються на короткі (const a = true). * Інтуїтивно: Комп’ютеру байдуже на красу коду, йому важливий розмір файлу.

4. Tree Shaking ("Трясіння дерева")

Це мій улюблений термін. Уявіть, що ви підключили величезну бібліотеку "Математика", але використовуєте з неї лише функцію 2 + 2. Навіщо вам тягнути весь підручник? Build-процес "трясе дерево" вашого коду, і все "мертве листя" (функції, які ви не використали) відпадає і не потрапляє у фінальний файл.

❗️ Що треба запам'ятати: Development build — для вас (швидко оновлюється, читабельний, зручний для дебагу). Production build — для користувача (маленький, швидкий, оптимізований).

3. 🧪 Приклади (Від простого до реального)

Приклад 1: Мініфікація

Питання до вас: Як ви думаєте, наскільки меншим стане код, якщо прибрати пробіли?

Ваш код (Source):

// Функція додавання
function addNumbers(first, second) {
    const result = first + second;
    return result;
}

(Розмір: ~100 байт)

Код після Build (Output):

function a(b,c){return b+c}

(Розмір: ~25 байт)

Результат: Ми зменшили розмір у 4 рази! А логіка залишилась тією ж.

Приклад 2: Змінні середовища (Environment Variables)

Уявіть, що ваш код звертається до сервера (API). * Коли ви вдома, це localhost:3000. * Коли сайт в інтернеті, це api.mysite.com.

Ви ж не будете щоразу вручну переписувати код перед завантаженням?

Ваш код:

console.log("Connecting to:", process.env.API_URL);

Build для розробки (Dev): Збирач підставляє: Connecting to: localhost:3000

Build для продакшну (Prod): Ви пишете команду npm run build. Збирач бачить, що це режим "production", і замінює код назавжди: console.log("Connecting to: api.mysite.com");

Це магія підстановки значень під час збірки.

4. 🛠 Практична частина

Час закачати рукави! Ось ваші завдання.

Завдання 1: Роль "мініфікатора" Ви — збирач. Мініфікуйте цей код вручну (на папері або в голові), зберігаючи логіку:

const taxRate = 0.2;
const price = 100;
// Рахуємо податок
const total = price + (price * taxRate);
console.log(total);

(Підказка: скоротіть назви, приберіть коментарі).

Завдання 2: Логіка Tree Shaking У вас є файл utils.js з трьома функціями: eat(), sleep(), code(). У головному файлі main.js ви написали:

import { code } from './utils.js';
code();

Питання: Які функції потраплять у фінальний bundle.js після Tree Shaking? Чому?

Завдання 3: Виправ помилку новачка Студент запустив команду npm run build. У папці проєкту з'явилася папка dist (distribution) з готовими файлами. Він бере і починає редагувати код прямо всередині папки dist, щоб змінити колір кнопки. Чому це фатальна помилка? Що станеться при наступній збірці?

Завдання 4: Міні-кейс Ви робите сайт новин. На головній сторінці показується лише текст. Але якщо натиснути "Показати погоду", має завантажитися величезний модуль з мапами та графіками. Як би ви налаштували збірку, щоб цей важкий модуль не завантажувався одразу з усіма новинами? (Підказка: це називається "Code Splitting" або "Ліниве завантаження").

5. 💡 Мислення як у розробника

Послухайте уважно. Ось де новачки найчастіше спотикаються, а досвідчені профі перемагають.

  1. "Папка dist / build — це сміття". Ніколи, чуєте, НІКОЛИ не редагуйте файли у папці збірки. Це артефакт. Це як намагатися виправити помилку в книзі, пишучи ручкою по надрукованому тиражу. Треба виправити рукопис (source) і передрукувати (build) тираж. Порада: Додайте папку dist у .gitignore. Їй не місце у вашому репозиторії.

  2. Dev != Prod. Те, що працює у вас локально, може зламатися після мініфікації. Наприклад, якщо ваш код покладався на конкретні імена функцій, а мініфікатор змінив їх на a() та b(). Тому завжди тестуйте саме production build перед релізом.

  3. Мислення "Ваги". Розробник думає про байти. Кожен імпорт бібліотеки — це вага.

    • Новачок: "О, мені треба відформатувати дату, підключу бібліотеку moment.js на 200кб!"
    • Профі: "Мені треба тільки дату? Напишу одну функцію на 3 рядки або візьму легку date-fns".

6. 🧩 Підсумок

Отже, що ми сьогодні зрозуміли? Ми дізналися, що між вашим кодом і браузером користувача стоїть Збірка (Build). Це "магічний" завод, який: 1. Склеює файли (Bundling). 2. Стискає їх (Minification). 3. Викидає зайве (Tree Shaking). 4. Перекладає для браузерів (Transpilation).

Тепер ви вмієте не просто писати код, а розумієте, як підготувати його до реального життя.

🚀 Тизер: Але стривайте! У нас є папка dist з готовим сайтом. Вона лежить у вас на комп'ютері. Як її побачить світ? На наступному уроці ми поговоримо про Deployment та CI/CD — як автоматично доставити вашу "піцу" клієнту, поки ви п'єте каву.

Це був CS50... тобто, урок про Збірку. Побачимось!

← До списку уроків Наступний урок →