Пошук уроків, статей та іншого контенту
Розберете відмінності production-режиму Next.js та підготуєте застосунок до стабільного розгортання.
Next.js має два основні режими роботи:
development — режим розробки, який запускається командою next dev;
production — підготовлена та оптимізована версія застосунку.
У development-режимі Next.js:
швидко перебудовує змінені файли;
показує детальні повідомлення про помилки;
підтримує гаряче оновлення сторінки;
не оптимізує застосунок для реальних користувачів.
Production-версія проходить окремий процес збірки. Next.js оптимізує код, створює сторінки та готує файли для запуску на сервері.
Послідовність команд для production така:
next build → next startКоманда next start не створює збірку самостійно. Перед її запуском потрібно виконати next build.
package.jsonЗазвичай у проєкті Next.js мають бути такі скрипти:
{
"scripts": {
"dev": "next dev",
"build": "next build",
"start": "next start"
}
}Тепер застосунок можна запускати в різних режимах:
# Розробка
npm run dev
# Створення production-збірки
npm run build
# Запуск уже створеної production-збірки
npm run startПовна послідовність локальної перевірки:
npm install
npm run build
npm run startПісля npm run start застосунок зазвичай буде доступний за адресою http://localhost:3000.
Для запуску на іншому порту можна використати змінну PORT:
PORT=4000 npm run startУ Windows PowerShell команда має такий вигляд:
$env:PORT=4000
npm run startПорт часто задається середовищем розгортання, тому не варто жорстко прив’язувати застосунок лише до порту 3000.
next buildКоманда npm run build:
перевіряє застосунок;
компілює код;
створює оптимізовану production-збірку;
готує сторінки та серверні частини застосунку;
зберігає результат у службовій директорії .next.
Приклад:
npm run buildУ консолі Next.js виводить інформацію про сторінки та їхній тип. Під час збірки можуть бути виявлені:
синтаксичні помилки;
відсутні модулі;
помилки TypeScript;
проблеми під час попереднього рендерингу;
некоректне використання серверного або клієнтського коду.
Якщо збірка завершилася з помилкою, production-застосунок запускати зарано. Спочатку потрібно виправити помилку й повторити npm run build.
Режим next dev не є заміною production-перевірці. Навіть якщо сторінка працює в development-режимі, помилка може з’явитися під час збірки.
Приклад простого циклу перевірки:
# Встановлюємо саме версії з lock-файла
npm ci
# Створюємо production-збірку
npm run build
# Запускаємо production-сервер
npm run startnpm ci зручно використовувати в CI або під час розгортання, якщо в репозиторії є package-lock.json. Команда встановлює залежності відповідно до lock-файла, а не підбирає нові версії.
Після запуску потрібно вручну перевірити основні сценарії:
відкриття головної сторінки;
перехід між сторінками;
відправлення форм;
завантаження даних;
відображення помилок;
роботу сторінок із динамічними параметрами.
Production-застосунок часто використовує значення, які не потрібно зберігати безпосередньо в коді:
URL API;
ключі доступу до сервісів;
налаштування бази даних;
режим роботи застосунку.
Для production можна створити файл .env.production.local:
API_URL=https://api.example.com
INTERNAL_API_KEY=секретне-значенняСекретні файли не повинні потрапляти до Git. Перевірте, що .env*.local додано до .gitignore.
У серверному коді змінну можна прочитати через process.env:
export async function GET() {
const apiUrl = process.env.API_URL;
if (!apiUrl) {
return Response.json(
{ error: "API_URL не налаштовано" },
{ status: 500 }
);
}
return Response.json({ apiUrl });
}Змінні з префіксом NEXT_PUBLIC_ можуть потрапити до браузерного коду:
NEXT_PUBLIC_API_URL=https://api.example.comТому не можна зберігати секрети в таких змінних. Наприклад, ключ доступу до бази даних не повинен мати префікс NEXT_PUBLIC_.
Перед production-збіркою переконайтеся, що всі необхідні змінні налаштовані в середовищі розгортання. Якщо змінна використовується під час збірки, вона має бути доступною вже на етапі npm run build.
.gitignoreСлужбові та локальні файли не потрібно додавати до репозиторію. Мінімальний .gitignore для Next.js може містити:
node_modules
.next
.env*.localПапка .next створюється під час збірки, тому її не потрібно комітіти. На сервері або в CI вона буде створена заново командою npm run build.
Файл lock-залежностей, навпаки, потрібно зберігати в репозиторії:
package-lock.jsonВін допомагає встановлювати однакові версії пакетів у різних середовищах.
next start без збіркиПомилка виникає, якщо виконати:
npm run startдо:
npm run buildПравильний порядок:
npm run build
npm run startКоманда:
npm run devпризначена для розробки, а не для production. Вона використовує інший режим роботи та не дає готової оптимізованої збірки.
Для production використовуйте:
npm run build
npm run startЗастосунок може запускатися локально через наявний .env.local, але не працювати після розгортання, якщо змінні не додані до production-середовища.
Перевірте:
назви змінних;
доступність змінних під час збірки;
відсутність зайвих пробілів;
правильність URL та ключів;
чи не використовує клієнтський код серверний секрет.
Якщо змінити код після виконання npm run build, команда npm run start не підхопить ці зміни автоматично. Потрібно знову створити збірку:
npm run build
npm run startРізні версії залежностей можуть спричинити різну поведінку локально та на сервері. Для стабільного встановлення залежностей зберігайте lock-файл і використовуйте:
npm ciПеред публікацією застосунку перевірте:
У package.json є скрипти build і start.
У репозиторії збережено lock-файл.
Локально успішно виконуються npm ci та npm run build.
Production-версія запускається через npm run start.
Усі необхідні змінні середовища налаштовані.
Секрети не мають префікса NEXT_PUBLIC_.
Файли .env*.local, node_modules і .next не зберігаються в Git.
Основні сценарії перевірені саме в production-режимі.
next dev використовується під час розробки.
next build створює оптимізовану production-збірку.
next start запускає вже створену збірку.
Перед розгортанням потрібно перевірити змінні середовища та залежності.
Production-збірку варто перевіряти локально до публікації застосунку.
Надійний базовий процес має вигляд:
npm ci
npm run build
npm run start