Node.js 24 перейшов у LTS 28 жовтня 2025 року під кодовою назвою Krypton і отримуватиме оновлення до кінця квітня 2028 року. Міграція з Node.js 22 охоплює зміни двох major-гілок, тому її слід виконувати через офіційний migration guide, а не просту заміну образу.
Перевірте підтримку пакетів
Знайдіть native addons, deprecated API, custom loaders, test runners та instrumentation. Пакет може встановитися, але використовувати поведінку, що змінилася у Node 23 або 24. Запускайте тести з чистим lockfile і кешем.
Стандарти Web API розширюють платформу
Сучасний Node включає більше браузерних API, але їх семантика не завжди тотожна старим стороннім бібліотекам. Не міняйте HTTP client, streams і URL handling одночасно з runtime, якщо не маєте окремого набору сумісності.
ESM і CommonJS потребують явної межі
Перевірте package type, exports, conditional imports і тестове середовище. Помилки часто проявляються лише в опублікованому пакеті, тому тестуйте tarball або реальний registry artifact.
Native addons треба перезібрати
Навіть N-API зменшує, але не усуває операційні ризики. Перевірте доступність prebuilt binaries для всіх архітектур, версію glibc або musl і поведінку fallback-компіляції.
Не ігноруйте patch-релізи
LTS означає стабільну лінію, а не незмінний binary. Security fixes виходять регулярно. Закріплюйте major, але автоматизуйте контрольоване оновлення patch із тестами й SBOM.
Чекліст
- прочитайте v22-to-v24 guide;
- оновіть npm і lockfile свідомо;
- перевірте native modules;
- запустіть тести ESM/CJS;
- порівняйте memory та event-loop delay;
- перевірте signals і graceful shutdown;
- розгорніть canary.
Стабільність вимірюється в production-подібному середовищі
Матеріал TechPulse про профілювання допоможе знайти регресії, а стаття про SLSA — контролювати походження Node.js-образів.
Спочатку зафіксуйте реальну платформу виконання
Міграція починається не з локальної заміни бінарного файла, а з інвентаризації всіх середовищ: образів контейнерів, CI runners, serverless-функцій, скриптів адміністрування та робочих станцій. Запишіть версію Node.js, менеджер пакетів, базовий Linux-образ, архітектуру процесора й параметри запуску. Окремо позначте native addons, бо вони залежать від ABI, компілятора та системних бібліотек. Такий перелік показує, де достатньо нового runtime, а де потрібне повне перевстановлення залежностей.
Залежності потрібно перевіряти на чистому встановленні
Створіть окрему гілку, видаліть старий каталог залежностей і виконайте інсталяцію лише з lockfile. Перевірте, чи немає пакетів із застарілими engine-обмеженнями, postinstall-скриптів або покинутих native-модулів. Далі запустіть unit, integration та end-to-end тести з увімкненими попередженнями. Для TypeScript-проєкту узгодьте перехід із матеріалом про TypeScript 5.9 і режим Node.js, щоб зміна компілятора не маскувала проблеми нового runtime.
Продуктивність вимірюйте на однаковому навантаженні
Порівняйте версії 22 і 24 на зафіксованому наборі запитів, однаковій кількості процесів та незмінних лімітах CPU і пам’яті. Збирайте не лише середню затримку, а p95, p99, споживання heap, паузи збирача сміття, швидкість старту та кількість помилок. Окремо проведіть тривалий прогін, щоб побачити витік пам’яті або поступове зростання event-loop lag, якого не покаже короткий benchmark.
Розгортання має залишати швидкий шлях назад
Зберіть окремий незмінний образ і спочатку направте на нього невелику частку трафіку. Canary має обробляти реальні запити, але мати власні метрики та журнали. Критеріями відкату можуть бути зростання частки 5xx, p99, пам’яті або часу виконання фонової черги. Не оновлюйте одночасно базовий дистрибутив і кілька ключових бібліотек: невеликий diff значно спрощує пошук причини регресії.
Після переходу приберіть приховану залежність від Node.js 22
Перевірте Dockerfile, workflow, документацію, версійні файли та шаблони нових сервісів. Забороніть старий runtime у CI, але збережіть попередній образ на обмежений строк для аварійного відкату. Оновіть runbook і зафіксуйте результати сумісності залежностей. Якщо команда оцінює альтернативні runtime, порівнюйте їх окремим експериментом, а не змішуйте міграцію LTS із переходом на іншу платформу, наприклад описану в матеріалі про Deno 2.7.
Контрольний чекліст міграції Node.js 24
До production команда повинна підтвердити чисте встановлення lockfile, збірку native addons, unit та integration tests, готовий container image, canary і rollback. Додайте перевірку потоків, worker threads, child processes, TLS, DNS, proxy та graceful shutdown. Фоновий job має коректно завершуватися під SIGTERM і не залишати незавершену транзакцію. Для CLI окремо виміряйте startup на холодному файловому кеші.
Після випуску зафіксуйте version, digest образу, залежності та результати benchmark у release note. Власник протягом періоду спостереження порівнює event-loop lag, heap, restart і помилки зі старою базовою лінією. Завершеною міграція стає тоді, коли новий сервіс можна відтворити з repository, а стару версію неможливо випадково повернути наступною автоматичною збіркою.
Коли міграцію варто відкласти
Не переходьте, якщо критичний native addon не має підтримуваної збірки, staging не відтворює production або rollback існує лише на словах. Спочатку усуньте блокер і додайте його до автоматичного тесту. Відкладення має мати власника, дату та захисні оновлення для Node.js 22, а не перетворюватися на безстрокове використання старого LTS.
Готовність означає не нуль попереджень, а контрольований список відомих відмінностей із виміряним впливом. Якщо canary стабільний під реальним піком, команда відтворює збірку й аварійно повертає попередній образ, ризик переходу стає керованим.
Першоджерело: офіційний посібник міграції Node.js 22→24.
Коментарі
Щоб залишити коментар, увійдіть через Google.