Node.js 26.13.0 با نام رمز «Lithium» در ۲۸ اکتبر منتشر شد و خط 26.x را از Current به پشتیبانی بلندمدت (LTS) برد. طبق یادداشت انتشار، جز فراداده‌هایی مثل شیء process.release که حالا وضعیت LTS را نشان می‌دهد، هیچ تغییری نسبت به 26.12.1 ندارد. پس این یک انتشار قابلیت‌محور نیست، بلکه یک علامت است: این خط حالا برای production در نظر گرفته شده و تا پایان آوریل ۲۰۲۹ نگهداری می‌شود.
برای تیم فرانت‌اند، نکته‌ی جالب خودِ بسته نیست. جاهایی است که نسخه‌ی Node را در آن‌ها قفل کرده‌اید و کاری که LTS جدید با آن قفل‌ها می‌شود کرد.
دقیقاً چه چیزی عوض شد
سه چیز، که هیچ‌کدام در کد برنامه‌ی شما نیست:
- وضعیت. صفحه‌ی نسخه‌های قبلی نسخه‌ی v26 (اولین انتشار ۵ مه ۲۰۲۶) را LTS نشان می‌دهد، کنار v24 با نام «Krypton» و v22 با نام «Jod» که آن‌ها هم LTS هستند. توصیه‌ی همان صفحه این است که در production فقط از خط‌های Active یا Maintenance LTS استفاده شود.
- فراداده‌ی runtime.
process.releaseوضعیت LTS را گزارش می‌کند. اگر ابزاری دارید که رویprocess.release.ltsشرط می‌گذارد (بعضی بررسی‌گرهای نسخه و محافظ‌های CI چنین‌اند)، از حالا 26 را می‌پذیرد. - بازه‌ی پشتیبانی. طبق یادداشت انتشار، به‌روزرسانی‌ها تا پایان آوریل ۲۰۲۹ ادامه دارد.
رفتار runtime دقیقاً همان 26.12.1 است، پس هر چه روی خط Current اعتبارسنجی کرده‌اید منتقل می‌شود. خودِ 26.12.1 در ۲۱ اکتبر یک انتشار امنیتی بود و طبق فهرست انتشارهای GitHub همراه نسخه‌های وصله‌شده‌ی خط‌های 24.x و 22.x آمد. اگر پایپ‌لاین‌هایتان هنوز روی 26.x قدیمی‌تری است، 26.13.0 راه گرفتن آن وصله هم هست.
چرخه‌ی انتشار هم عوض می‌شود
صفحه‌ی نسخه‌های قبلی می‌گوید از Node.js 27 به بعد انتشارها سالانه می‌شوند: هر نسخه‌ی major پس از شش ماه فاز Current به LTS می‌رود و بعد شش ماه فاز Alpha دارد. من این را دلیلی می‌دانم که نسخه‌های major زوج را مدت‌ها پیش‌فرض خود بگیرید، اما صفحه زمان‌بندی کامل را شرح نمی‌دهد؛ پیش از برنامه‌ریزی مهاجرت به 27 آن را بررسی کنید.
چرا برای پروژه‌های Nuxt مهم است
Nuxt 4.6 کف نسخه را بالا برد. طبق صفحه‌ی انتشارهای Nuxt، به Node.js نسخه‌ی v22.21+ یا v24.11+ یا v26+ نیاز دارد. یعنی 26 هدف پشتیبانی‌شده و حالا LTS است. اگر امروز روی 22 هستید، چیزی شما را مجبور به جابه‌جایی نمی‌کند چون 22 هنوز LTS است. اما برای ایمیج استقرار جدید حالا بین سه خط LTS انتخاب دارید و بلندترین مسیر پشتیبانی مال 26 است.
همان صفحه نشان می‌دهد هشدارهای امنیتی سمت سرور چقدر سریع می‌رسند: Nuxt 4.6.3 (۲۷ اکتبر) پنج رفع امنیتی داشت. اجرا روی خطی از Node که هنوز وصله‌ی امنیتی می‌گیرد نیمه‌ی دیگر همین ماجراست.
با قفل‌های نسخه چه کنیم
جاهای معمولی که نسخه‌ی Node در آن‌ها پنهان است:
# Dockerfile
FROM node:26-alpine AS runtime
// package.json
{
"engines": { "node": ">=22.21.1" }
}
# .github/workflows/ci.yml
- uses: actions/setup-node@v4
with:
node-version: 26
چند نکته‌ی عملی:
- در CI major را قفل کنید، در production digest را. تگ major مثل
node:26-alpineوصله‌های 26.x را خودکار دنبال می‌کند و برای رفع‌های امنیتی همین را می‌خواهید. برای استقرار تکرارپذیر، digest ایمیج را قفل کنید و عمداً ارتقا دهید. نام دقیق تگ‌ها را در Docker Hub برای این نوشته بررسی نکرده‌ام؛ پیش از تکیه بر آن مطمئن شوید تگ شما به 26.13.0 می‌رسد. enginesرا گسترده کنید، نه تنگ. اگر روی 22 و 24 و 26 تست می‌کنید،enginesهم باید همین را بگوید. یک کف>=منطبق با حداقل فریم‌ورک معمولاً کافی است.- اول ماتریس، بعد حذف یک خط. حالا 26 را به ماتریس CI اضافه کنید. وقتی سبز شد می‌توانید تصمیم بگیرید 22 را کنار بگذارید یا نه؛ تاریخ پایان پشتیبانی 22 در صفحه‌ی نسخه‌های قبلی فقط در ستونی با عنوان «last updated» آمده که نتوانستم بدون ابهام تفسیرش کنم. برای مرحله‌ی دقیق، برنامه‌ی رسمی در GitHub را ببینید.
نکته‌ی libatomic
یک خط در یادداشت انتشار هست که راحت از آن می‌گذرند و در کانتینر مینیمال گیرتان می‌اندازد. از Node.js 25 به بعد، باینری‌های رسمی لینوکس با libatomic لینک می‌شوند. اگر از LTS قبلی (22 یا 24) ارتقا می‌دهید، بسته به توزیع ممکن است لازم باشد آن را جداگانه نصب کنید.
اگر روی پایه‌ی slim یا شبیه distroless بیلد می‌کنید و باینری Node را کپی می‌کنید، ارتقا همین‌جا نه در زمان بیلد بلکه هنگام راه‌اندازی شکست می‌خورد. یک smoke test در بیلد ایمیج آن را می‌گیرد:
RUN node --version && node -e "console.log(process.release.lts)"
اگر از ایمیج رسمی Node استفاده می‌کنید، پایه باید آنچه لازم است داشته باشد، ولی این را بررسی نکرده‌ام، پس smoke test را در هر حال اجرا کنید. اگر runtime را خودتان می‌سازید، بسته‌ی libatomic توزیع خود را اضافه کنید و دوباره تست بگیرید.
بده‌بستان: حالا برویم یا صبر کنیم؟
دلایل رفتن حالا:
- بلندترین افق پشتیبانی بین سه خط LTS، تا آوریل ۲۰۲۹.
- هیچ تفاوت رفتاری با 26.12.1 نیست، پس تیم‌هایی که روی Current هستند چیزی برای اعتبارسنجی دوباره ندارند.
- با بازه‌ی نیازمندی Nuxt 4.6 هم‌خوان است، یعنی لبه‌ی چیزی که فریم‌ورک پشتیبانی می‌کند نیستید.
دلایل ماندن روی 22 یا 24 برای مدتی:
- ارتقای major در Node هنوز می‌تواند addonهای native را به هم بزند. هر چیزی که روی ABI نود کامپایل می‌شود، مثل
better-sqlite3که همین سایت برای Nuxt Content به کار می‌برد، باید دوباره ساخته شود یا برای major جدید باینری آماده داشته باشد. مرحله‌ی نصب را تست کنید، نه فقط برنامه را. - اگر پلتفرم میزبانی شما هنوز 26 را به runtime مدیریت‌شده‌اش اضافه نکرده، جلوتر بودن سودی ندارد.
- ارتقا به LTS گواهی درستی نیست. یعنی پروژه به نگهداری متعهد است؛ نه اینکه درخت وابستگی‌های شما به‌روز شده باشد.
چک‌لیست کوتاه ارتقا
- Node 26 را به ماتریس CI اضافه کنید و install، lint، typecheck، تست‌های واحد و E2E را اجرا کنید.
- وابستگی‌های native را دوباره بسازید و وجود باینری آماده را بررسی کنید.
- ایمیج production را روی 26 بسازید و smoke test مربوط به
libatomicرا اجرا کنید. - چند روز در staging زیر ترافیک واقعی اجرا کنید و حافظه و تأخیر event loop را زیر نظر بگیرید.
engines،.nvmrcیا.node-versionو Dockerfile را در یک commit به‌روز کنید تا هرگز با هم ناهمخوان نباشند.
این ارتقا به LTS را محرکی برای آن چک‌لیست بدانید، نه خودِ ارتقا.