Інструменти налагодження та розробки
Інструменти налагодження та розробки
🎯 Мета лекції
- Опанувати вбудовані інструменти налагодження Node.js:
node inspectта Chrome DevTools. - Навчитися налагоджувати TypeScript-код безпосередньо у VS Code через launch.json.
- Освоїти інструменти продуктивності розробки:
nodemon,ts-node,tsx. - Вивчити управління версіями Node.js через
nvmтаfnm. - Зрозуміти методи профілювання та аналізу продуктивності застосунків.
🔑 Ключові терміни
- Debugger: інструмент для покрокового виконання коду, інспектування змінних та аналізу call stack.
- Breakpoint: точка зупинки виконання програми для дослідження стану у конкретний момент.
- Inspector Protocol: протокол Node.js для підключення зовнішніх debugger-клієнтів (Chrome DevTools, VS Code).
- Hot Reload: автоматичний перезапуск застосунку при зміні вихідних файлів.
- Profiling: аналіз продуктивності програми для виявлення вузьких місць (bottlenecks).
Еволюція налагодження: від console.log до Inspector Protocol
Антипаттерн: налагодження через console.log
Найпростіший, але найменш ефективний спосіб налагодження — вставлення console.log() у різні місця коду:
function calculateDiscount(price: number, customerType: string): number {
console.log('calculateDiscount викликано з:', price, customerType); // 🐛 Debug
let discount = 0;
if (customerType === 'premium') {
discount = 0.2;
console.log('Premium клієнт, знижка 20%'); // 🐛 Debug
} else if (customerType === 'regular') {
discount = 0.1;
console.log('Regular клієнт, знижка 10%'); // 🐛 Debug
}
const finalPrice = price * (1 - discount);
console.log('Фінальна ціна:', finalPrice); // 🐛 Debug
return finalPrice;
}
const result = calculateDiscount(100, 'premium');
console.log('Результат:', result); // 🐛 Debug
Проблеми цього підходу:
- Забруднення коду: Debug-логи змішуються з бізнес-логікою та потрапляють у production.
- Відсутність контексту: Важко зрозуміти весь шлях виконання та стан програми.
- Ручне видалення: Після налагодження потрібно видаляти всі
console.log(), що може призвести до пропуску деяких. - Обмежені можливості: Неможливо змінити значення змінної під час виконання або перемотати стек викликів назад.
console.log() залишається корисним для швидких перевірок та логування у production, але не замінює повноцінний debugger для розслідування складних багів.Рішення: інтерактивні debugger
Сучасні debugger надають:
- Breakpoints: Зупинка виконання у конкретних рядках коду.
- Step-through execution: Покрокове виконання (step over, step into, step out).
- Variable inspection: Перегляд та модифікація значень змінних у реальному часі.
- Call stack navigation: Перегляд ланцюга викликів функцій.
- Conditional breakpoints: Зупинка лише за виконання певної умови.
- Watch expressions: Відстеження значень виразів протягом виконання.
Вбудований Node.js Debugger: node inspect
Node.js має вбудований CLI-debugger, який працює безпосередньо у терміналі. Він корисний для швидкого налагодження без налаштування IDE.
Запуск у режимі налагодження
// app.ts
function fibonacci(n: number): number {
if (n <= 1) return n;
return fibonacci(n - 1) + fibonacci(n - 2);
}
debugger; // 🔴 Точка зупинки
const result = fibonacci(10);
console.log('Fibonacci(10) =', result);
Запуск із вбудованим debugger:
Команди debugger у терміналі
exec n покаже значення змінної n.watch('result').list(10) покаже 10 рядків.Приклад інтерактивної сесії
debugger; у коді еквівалентно встановленню breakpoint. Коли Node.js запущено у режимі налагодження (node inspect або node --inspect), виконання зупиниться на цьому рядку.Chrome DevTools: графічний інтерфейс налагодження
Node.js підтримує Inspector Protocol, що дозволяє підключати Chrome DevTools для візуального налагодження з усіма можливостями браузерного debugger.
Запуск у режимі inspect
# Запуск із дефолтним портом 9229
node --inspect server.js
# Або відразу з паузою на першому рядку
node --inspect-brk server.js
# Кастомний порт
node --inspect=0.0.0.0:9230 server.js
Підключення Chrome DevTools
Крок 1: Відкрийте Chrome
Відкрийте браузер Google Chrome (або будь-який Chromium-based: Edge, Brave, Vivaldi).
Крок 2: Перейдіть до інспектора
У адресному рядку введіть:
chrome://inspect
Крок 3: Знайдіть процес Node.js
У розділі Remote Target з'явиться ваш Node.js процес:
Target (v20.x.x): /path/to/server.js
inspect
Крок 4: Клікніть "inspect"
Відкриється DevTools з повним доступом до:
- Sources: Перегляд коду з breakpoints
- Console: Інтерактивна консоль у контексті застосунку
- Memory: Профілювання пам'яті (heap snapshots)
- Profiler: CPU profiling для пошуку вузьких місць
--inspect-brk, який зупиняє виконання на першому рядку, даючи час підключити debugger перед стартом застосунку.Встановлення breakpoints у Chrome DevTools
У вкладці Sources ви можете:
- Клікнути на номері рядка — встановити звичайний breakpoint.
- ПКМ на номері рядка → Add conditional breakpoint — зупинка лише за умови:
userId === 42 // Зупинитися тільки для користувача з ID 42 - ПКМ на номері рядка → Add logpoint — вивести повідомлення без зупинки:
"User logged in:", username - Event Listener Breakpoints (права панель):
- XHR/fetch breakpoints — зупинка на AJAX-запитах
- Timer breakpoints — на
setTimeout,setInterval - Script breakpoints — на динамічному
eval()
VS Code Debugger: інтегроване налагодження
VS Code має вбудований debugger, який працює через Inspector Protocol Node.js. Це найзручніший спосіб налагодження для повсякденної розробки.
Автоматична конфігурація (JavaScript Runtime)
VS Code автоматично розпізнає Node.js проєкти. Для швидкого старту:
- Відкрийте файл із кодом (наприклад,
server.ts) - Натисніть F5 або перейдіть до Run → Start Debugging
- Оберіть Node.js у списку середовищ
VS Code автоматично створить конфігурацію та запустить debugger.
Ручна конфігурація через launch.json
Для детального контролю створіть файл .vscode/launch.json у корені проєкту:
{
"version": "0.2.0",
"configurations": [
{
"type": "node",
"request": "launch",
"name": "Launch Program",
"skipFiles": ["<node_internals>/**"],
"program": "${workspaceFolder}/src/server.js",
"outFiles": ["${workspaceFolder}/dist/**/*.js"]
}
]
}
{
"version": "0.2.0",
"configurations": [
{
"type": "node",
"request": "launch",
"name": "Debug TypeScript",
"skipFiles": ["<node_internals>/**"],
"runtimeArgs": ["-r", "ts-node/register"],
"args": ["${workspaceFolder}/src/server.ts"],
"env": {
"NODE_ENV": "development"
},
"console": "integratedTerminal"
}
]
}
{
"version": "0.2.0",
"configurations": [
{
"type": "node",
"request": "launch",
"name": "Debug with tsx",
"runtimeExecutable": "tsx",
"runtimeArgs": ["--inspect-brk"],
"program": "${workspaceFolder}/src/server.ts",
"skipFiles": ["<node_internals>/**"],
"console": "integratedTerminal"
}
]
}
{
"version": "0.2.0",
"configurations": [
{
"type": "node",
"request": "attach",
"name": "Attach to Process",
"port": 9229,
"restart": true,
"skipFiles": ["<node_internals>/**"]
}
]
}
Пояснення ключових параметрів
"node"."launch" (запустити новий процес) або "attach" (підключитися до існуючого).${workspaceFolder}, ${file} (поточний файл).["-r", "dotenv/config"] для завантаження .env.<node_internals>/** пропускає внутрішній код Node.js."integratedTerminal" (вбудований термінал VS Code) або "internalConsole" (Debug Console).{ "NODE_ENV": "test", "DEBUG": "*" }.Встановлення breakpoints у VS Code
Спосіб 1: Клік на полі номерів рядків
Клікніть ліворуч від номера рядка — з'явиться червона точка 🔴.
Спосіб 2: Клавіша F9
Поставте курсор на потрібний рядок та натисніть F9 для toggle breakpoint.
Спосіб 3: Conditional Breakpoint
ПКМ на breakpoint → Edit Breakpoint → введіть умову:
userId === 42 && status === 'active'
Зупинка відбудеться лише за виконання умови.
Спосіб 4: Logpoint
ПКМ на breakpoint → Edit Breakpoint → Logpoint → введіть повідомлення:
User {username} logged in at {new Date().toISOString()}
Повідомлення виводиться у Debug Console без зупинки виконання.
Контроль виконання у VS Code
Під час налагодження доступна панель керування:
Continue (F5)
Step Over (F10)
Step Into (F11)
Step Out (Shift+F11)
Restart (Ctrl+Shift+F5)
Stop (Shift+F5)
Інспектування змінних
У лівій панелі VARIABLES відображаються:
- Local: Змінні поточної функції
- Global: Глобальні об'єкти (
process,console,Buffer) - Closure: Змінні із замикань (closures)
Можна розгорнути об'єкти, змінити значення (клік на значення) та додати до Watch (ПКМ → Add to Watch).
Інструменти продуктивності розробки
nodemon: автоматичний перезапуск при зміні файлів
Під час розробки незручно вручну перезапускати сервер після кожної зміни коду. nodemon автоматично відстежує файли та перезапускає процес.
npm install --save-dev nodemon
pnpm add -D nodemon
yarn add -D nodemon
Використання у package.json:
{
"scripts": {
"dev": "nodemon src/server.ts",
"dev:inspect": "nodemon --inspect src/server.ts"
}
}
Конфігурація через nodemon.json
Для точного контролю створіть файл nodemon.json у корені проєкту:
{
"watch": ["src"],
"ext": "ts,js,json",
"ignore": ["src/**/*.test.ts", "node_modules"],
"exec": "ts-node --transpile-only src/server.ts",
"env": {
"NODE_ENV": "development",
"DEBUG": "app:*"
},
"delay": 1000,
"restartable": "rs"
}
"ts,tsx,js,json"."tsx src/server.ts".--transpile-only у ts-node вимикає перевірку типів для швидшого перезапуску. Перевірку типів можна запустити окремо через tsc --noEmit --watch у паралельному терміналі.ts-node: виконання TypeScript без компіляції
ts-node дозволяє запускати TypeScript-файли безпосередньо, без попередньої компіляції у JavaScript:
npm install --save-dev ts-node typescript @types/node
# Прямий запуск TypeScript-файлу
ts-node src/server.ts
# З налагодженням
node --inspect -r ts-node/register src/server.ts
# REPL (інтерактивна консоль)
ts-node
Конфігурація у tsconfig.json:
{
"compilerOptions": {
"target": "ES2022",
"module": "commonjs",
"esModuleInterop": true,
"skipLibCheck": true
},
"ts-node": {
"transpileOnly": true,
"files": true,
"compilerOptions": {
"module": "commonjs"
}
}
}
ts-node компілює TypeScript у пам'яті (in-memory) під час виконання, тому перший запуск може бути повільнішим, ніж запуск попередньо скомпільованого JavaScript. Для production завжди використовуйте tsc для компіляції у статичні файли.tsx: швидша альтернатива ts-node
tsx — це сучасна заміна ts-node, написана на Rust (через esbuild), що забезпечує значно швидшу компіляцію:
npm install --save-dev tsx
# Запуск TypeScript
tsx src/server.ts
# Watch mode (автоперезапуск)
tsx watch src/server.ts
# З налагодженням
tsx --inspect src/server.ts
{
"scripts": {
"dev": "tsx watch src/server.ts",
"start": "node dist/server.js",
"build": "tsc"
}
}
Порівняння продуктивності:
ts-node
tsx
tsc. Інструменти на кшталт ts-node та tsx призначені виключно для розробки та тестування.Управління версіями Node.js
Різні проєкти можуть вимагати різних версій Node.js. Менеджери версій дозволяють швидко перемикатися між ними.
nvm (Node Version Manager): класичний інструмент
nvm — найпопулярніший менеджер версій Node.js для Unix-систем (macOS, Linux).
# Завантаження та встановлення nvm
curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.7/install.sh | bash
# Або через Homebrew (macOS)
brew install nvm
# Перезавантажте термінал або виконайте:
source ~/.bashrc # або ~/.zshrc
Для Windows використовуйте nvm-windows:
https://github.com/coreybutler/nvm-windows/releases
Завантажте nvm-setup.exe та встановіть через інсталятор.
Основні команди nvm
Файл .nvmrc: фіксація версії проєкту
Створіть файл .nvmrc у корені проєкту для автоматичного вибору версії:
20.11.0
Або з вказанням LTS:
lts/iron
Тепер команда nvm use автоматично зчитає версію з файлу:
cd /path/to/project
nvm use
# Found '.nvmrc' with version <20.11.0>
# Now using node v20.11.0
.nvmrc у Git, щоб вся команда використовувала однакову версію Node.js. Це запобігає проблемам із несумісністю залежностей або API.fnm (Fast Node Manager): швидка альтернатива
fnm написаний на Rust і працює у 10-40 разів швидше, ніж nvm. Він автоматично перемикає версію Node.js при зміні директорії (якщо знаходить .nvmrc або .node-version).
brew install fnm
# Додайте у ~/.zshrc або ~/.bashrc:
eval "$(fnm env --use-on-cd)"
curl -fsSL https://fnm.vercel.app/install | bash
# Додайте у ~/.bashrc:
eval "$(fnm env --use-on-cd)"
winget install Schniz.fnm
# Додайте у PowerShell profile:
fnm env --use-on-cd | Out-String | Invoke-Expression
Основні команди fnm
# Встановити версію
fnm install 20
# Використати версію
fnm use 20
# Показати встановлені версії
fnm list
# Встановити версію за замовчуванням
fnm default 20
# Встановити LTS версію
fnm install --lts
Автоматичне перемикання:
# У проєкті А (.nvmrc: 18.19.0)
cd ~/projects/legacy-app
node --version # v18.19.0 (автоматично!)
# У проєкті Б (.nvmrc: 20.11.0)
cd ~/projects/modern-app
node --version # v20.11.0 (автоматично!)
fnm підтримує як .nvmrc, так і .node-version файли. Якщо версія не встановлена, fnm запропонує встановити її автоматично.Профілювання продуктивності
Профілювання (profiling) — це процес аналізу того, де застосунок витрачає час виконання та пам'ять. Node.js надає вбудовані інструменти для виявлення вузьких місць (bottlenecks).
CPU Profiling: пошук повільних функцій
Node.js може генерувати CPU profile, який показує, скільки часу витрачено на кожну функцію:
# Запуск із профілюванням (V8 profiler)
node --prof server.js
# Після роботи застосунку з'явиться файл isolate-0x....-v8.log
# Обробка лог-файлу у читабельний формат:
node --prof-process isolate-0x....-v8.log > profile.txt
Результат у profile.txt:
[Summary]:
ticks total nonlib name
1582 39.6% 39.8% JavaScript
2403 60.2% 60.4% C++
2 0.1% 0.1% GC
268 6.7% Shared libraries
Детальна статистика функцій:
[JavaScript]:
ticks total nonlib name
234 5.9% 5.9% LazyCompile: *calculateDiscount /path/to/app.js:42:28
189 4.7% 4.7% LazyCompile: *queryDatabase /path/to/db.js:15:22
145 3.6% 3.6% RegExp: [a-zA-Z0-9]+
Chrome DevTools Profiler
Більш зручний спосіб — профілювання через Chrome DevTools:
Крок 1: Запустіть з inspect
node --inspect server.js
Крок 2: Відкрийте DevTools
Перейдіть до chrome://inspect та клікніть inspect.
Крок 3: Вкладка Profiler
У DevTools перейдіть до вкладки Profiler → Start.
Крок 4: Навантажте застосунок
Виконайте операції, які потрібно проаналізувати (HTTP-запити, обробка даних).
Крок 5: Зупиніть профілювання
Клікніть Stop — отримаєте інтерактивний flame graph.
Flame Graph показує:
- Горизонтальна вісь: Час виконання (ширина = тривалість функції).
- Вертикальна вісь: Глибина call stack (батьківські функції зверху, дочірні знизу).
- Колір: Hot functions (червоний/жовтий) — функції, що споживають найбільше CPU.
Memory Profiling: пошук витоків пам'яті
Node.js може створювати heap snapshots — знімки стану пам'яті у конкретний момент:
// Програмне створення heap snapshot
import v8 from 'node:v8';
import fs from 'node:fs';
function takeSnapshot(filename: string): void {
const snapshotStream = v8.writeHeapSnapshot(filename);
console.log(`Heap snapshot збережено у ${snapshotStream}`);
}
// Створення snapshot перед та після операції
takeSnapshot('./heap-before.heapsnapshot');
// Операція, яка може викликати витік пам'яті
const leakyArray: unknown[] = [];
for (let i = 0; i < 1_000_000; i++) {
leakyArray.push({ id: i, data: Buffer.alloc(1024) });
}
takeSnapshot('./heap-after.heapsnapshot');
Аналіз через Chrome DevTools:
Крок 1: Завантажте snapshot
У DevTools → Memory → Load → оберіть файл .heapsnapshot.
Крок 2: Порівняйте snapshots
Завантажте heap-before.heapsnapshot та heap-after.heapsnapshot.
Крок 3: Виберіть режим "Comparison"
DevTools покаже різницю: які об'єкти додалися та скільки пам'яті вони займають.
Крок 4: Знайдіть витік
Відсортуйте за колонкою Size Delta — найбільші значення вказують на витік.
Clinic.js: автоматичний аналіз продуктивності
clinic — це набір інструментів від команди Node.js для автоматичної діагностики:
# Встановлення
npm install -g clinic
# Clinic Doctor: виявлення проблем із Event Loop та I/O
clinic doctor -- node server.js
# Clinic Bubbleprof: візуалізація асинхронних операцій
clinic bubbleprof -- node server.js
# Clinic Flame: генерація flame graphs
clinic flame -- node server.js
# Після завершення тестування (Ctrl+C) відкриється HTML-звіт у браузері
Clinic Doctor виявляє:
- Event Loop затримки (блокуючий синхронний код)
- Повільне введення/виведення (файли, бази даних, мережа)
- Проблеми з garbage collection
Налагодження у production: безпечні практики
Логування замість debugger
У production-середовищі debugger не є опцією. Натомість використовуйте структуроване логування:
import pino from 'pino';
const logger = pino({
level: process.env.LOG_LEVEL || 'info',
transport:
process.env.NODE_ENV === 'development'
? { target: 'pino-pretty', options: { colorize: true } }
: undefined,
});
// Структуровані логи з контекстом
logger.info({ userId: 42, action: 'login' }, 'User logged in');
// Логування помилок зі stack trace
try {
throw new Error('Database connection failed');
} catch (err) {
logger.error({ err, context: { userId: 42 } }, 'Failed to process request');
}
debug, info, warn, error) для контролю об'єму логів у production. Встановіть LOG_LEVEL=error для мінімального виводу або LOG_LEVEL=debug для детальної діагностики.Error Tracking: Sentry, Rollbar, Bugsnag
Для автоматичного збору помилок у production використовуйте сервіси error tracking:
import * as Sentry from '@sentry/node';
// Ініціалізація Sentry
Sentry.init({
dsn: process.env.SENTRY_DSN,
environment: process.env.NODE_ENV,
tracesSampleRate: 0.1, // 10% запитів для performance monitoring
});
// Express інтеграція
app.use(Sentry.Handlers.requestHandler());
app.use(Sentry.Handlers.tracingHandler());
// Ваші routes...
// Error handler (має бути останнім middleware)
app.use(Sentry.Handlers.errorHandler());
// Ручне логування помилок
try {
await riskyOperation();
} catch (err) {
Sentry.captureException(err, {
tags: { userId: req.user?.id },
extra: { requestBody: req.body },
});
throw err;
}
Distributed Tracing: OpenTelemetry
Для мікросервісних архітектур використовуйте distributed tracing для відстеження запиту через всі сервіси:
import { NodeSDK } from '@opentelemetry/sdk-node';
import { getNodeAutoInstrumentations } from '@opentelemetry/auto-instrumentations-node';
import { JaegerExporter } from '@opentelemetry/exporter-jaeger';
const sdk = new NodeSDK({
traceExporter: new JaegerExporter({
endpoint: 'http://localhost:14268/api/traces',
}),
instrumentations: [getNodeAutoInstrumentations()],
});
sdk.start();
// Автоматично інструментує HTTP, Express, PostgreSQL, Redis тощо
Питання для самоконтролю
Технічно так, але категорично не рекомендується:
- Блокування виконання: Якщо Node.js запущено у debug-режимі (
--inspect), виконання зупиниться наdebugger;, блокуючи обробку всіх запитів. - Витік інформації: Inspector Protocol дозволяє віддаленим клієнтам виконувати довільний код, що є критичною вразливістю безпеки.
- Продуктивність: Debug-режим вимикає деякі оптимізації V8.
Альтернатива: Видаляйте debugger; перед deployment або використовуйте linter (ESLint правило no-debugger) для автоматичної перевірки.
Крок 1: Відкрийте порт debugger у Dockerfile:
EXPOSE 3000 9229
Крок 2: Запустіть Node.js з --inspect:
// package.json
{
"scripts": {
"start:debug": "node --inspect=0.0.0.0:9229 dist/server.js"
}
}
Крок 3: Прокиньте порт у docker-compose.yml:
services:
app:
ports:
- "3000:3000"
- "9229:9229" # Debugger port
command: npm run start:debug
Крок 4: Підключіть VS Code через Attach:
// .vscode/launch.json
{
"type": "node",
"request": "attach",
"name": "Docker: Attach",
"address": "localhost",
"port": 9229,
"localRoot": "${workspaceFolder}",
"remoteRoot": "/app"
}
tsx у 10-50 разів швидше за ts-node завдяки використанню esbuild (Rust) замість TypeScript Compiler API (JavaScript).
Benchmark (середній проєкт, ~50 файлів):
| Інструмент | Холодний старт | Гарячий перезапуск | Переваги |
|---|---|---|---|
ts-node | ~3-5 секунд | ~2-3 секунди | Повна сумісність з TypeScript, перевірка типів |
tsx | ~100-300 мс | ~50-100 мс | Миттєвий старт, вбудований watch mode |
tsc + node | ~8-12 секунд (компіляція) | ~50 мс (запуск) | Production-ready код |
Рекомендація: Використовуйте tsx для розробки, tsc для production.
Типові причини:
- IDE створює тимчасові файли: VS Code, WebStorm можуть створювати
.swp,~файли при збереженні.
Рішення: Додайте уnodemon.json:{ "ignore": ["**/*.swp", "**/*~"] } - Compilation output змінює файли: TypeScript компілює
.ts→.js, що trigger другий перезапуск.
Рішення: Використовуйтеtsxабоts-node --transpile-onlyбез окремої компіляції. - Затримка занадто мала: Кілька файлів зберігаються одночасно.
Рішення: Збільштеdelay:{ "delay": 2000 }
Симптоми:
- Зростання heap size:
process.memoryUsage().heapUsedпостійно зростає без стабілізації. - Out of Memory crashes: Процес завершується з помилкою
FATAL ERROR: CALL_AND_RETRY_LAST Allocation failed - JavaScript heap out of memory. - Повільнішання застосунку: Garbage Collector витрачає все більше часу.
Діагностика:
// Моніторинг пам'яті кожні 10 секунд
setInterval(() => {
const used = process.memoryUsage();
console.log({
heapUsed: `${Math.round(used.heapUsed / 1024 / 1024)} MB`,
heapTotal: `${Math.round(used.heapTotal / 1024 / 1024)} MB`,
external: `${Math.round(used.external / 1024 / 1024)} MB`,
});
}, 10000);
Типові причини витоків:
- Глобальні змінні, що накопичують дані
- Event listeners, які не видаляються
- Таймери (
setTimeout,setInterval), які не очищуються - Кеші без TTL або обмеження розміру
- Не закриті з'єднання з БД або файлові дескриптори
Підсумок: оптимальний workflow розробки
Крок 1: Налаштування проєкту
# Встановити інструменти розробки
npm install --save-dev nodemon tsx @types/node
# Створити .nvmrc для фіксації версії Node.js
echo "20.11.0" > .nvmrc
Крок 2: Конфігурація scripts
// package.json
{
"scripts": {
"dev": "tsx watch src/server.ts",
"dev:debug": "tsx --inspect-brk src/server.ts",
"build": "tsc",
"start": "node dist/server.js",
"type-check": "tsc --noEmit"
}
}
Крок 3: Налаштування VS Code
// .vscode/launch.json
{
"configurations": [
{
"type": "node",
"request": "launch",
"name": "Debug TypeScript",
"runtimeExecutable": "tsx",
"program": "${workspaceFolder}/src/server.ts",
"skipFiles": ["<node_internals>/**"]
}
]
}
Крок 4: Профілювання перед production
# Перевірка продуктивності
clinic doctor -- node dist/server.js
# Heap snapshot для аналізу пам'яті
node --heapsnapshot-signal=SIGUSR2 dist/server.js
# Відправити сигнал: kill -USR2 <pid>
✅ Розробка
tsx watchдля миттєвого перезапуску- VS Code Debugger для покрокового виконання
console.log()для швидких перевірок- Chrome DevTools для візуального профілювання
🧪 Тестування
NODE_ENV=testдля ізольованого середовища- Heap snapshots для виявлення витоків
- Clinic.js для автоматичного аналізу
- Load testing (autocannon, k6)
🚀 Production
- Компільований JavaScript (
tsc) - Структуроване логування (pino, winston)
- Error tracking (Sentry, Rollbar)
- Distributed tracing (OpenTelemetry, Jaeger)
У наступній лекції ми розглянемо best practices продуктивності Node.js: оптимізацію Event Loop, використання Worker Threads, кешування та стратегії масштабування застосунків.