ما الذي تغيّره فعليًا نهاية دعم Node.js 20
يتبع Node.js دورة حياة معلنة: يدخل الإصدار ذو الرقم الزوجي مرحلة Active LTS في أكتوبر، وينتقل إلى Maintenance LTS بعد سنة، ثم يتوقف. دخل Node.js 20 مرحلة Maintenance LTS في 22 أكتوبر 2024، وبلغ نهاية دعمه في 30 أبريل 2026. ومنذئذٍ لم تعد أي ثغرة في وقت التشغيل تُصحَّح عند المصدر: لا في محرك V8، ولا في مكتبة TLS المدمجة، ولا في محلّل HTTP. تستمر الشيفرة في العمل، لكن كل ثغرة تُنشر تبقى مفتوحة هناك.
ما يكلّفه وقت تشغيل مُجمّد
- ثغرات دون تصحيح — الثغرات المنشورة بعد 30 أبريل 2026 لن تتلقى أي تصحيح من المصدر؛ ولا يغلقها سوى الترقية إلى إصدار أحدث.
- حزم تتخلى عن الدعم — يرفع المشرفون قيمة الحقل
enginesفيpackage.jsonنحو الإصدارات التي لا تزال مدعومة؛ فينتهي التثبيت الجديد إلى الفشل، أو إلى تثبيتك على إصدارات قديمة. - صور أساس ثابتة — لم تعد صورة
node:20تتلقى أي تصحيح، لا لوقت التشغيل ولا لحزم النظام تحته؛ ويشير فحص الثغرات لديك إلى ذلك عند كل بناء. - تدقيقات تتعثر — وقت التشغيل منتهي الدعم خطر غير مقبول في مراجعات الأمان واستبيانات المورّدين.
- ترحيل طارئ — كلما اتسعت الفجوة ارتفعت كلفة التبديل؛ تنفيذه اليوم مشروع مخطط له، وتحمّله بعد حادثة ليس كذلك.
اعرف ما تشغّله خوادمك فعلًا
لا يخبرك node -v في الطرفية سوى بجزء من القصة: فالملف التنفيذي في جلستك ليس بالضرورة الذي يخدم الإنتاج. يحتفظ مدير العمليات بالإصدار الذي انطلق به، ويثبّت nvm عدة إصدارات لكل مستخدم، ويُجمّد ملف Dockerfile إصداره الخاص في سطر FROM node:20. أحصِ كل مصدر: pm2 jsonlist للعمليات الحية، وgrep -r 'FROM node' في ملفات Dockerfile، وحقل engines في كل package.json، والإصدار المثبّت في مسارات CI أو في أوقات التشغيل المُدارة لديك.
الترحيل دون تعطيل الإنتاج
إعداد الجرد قبل أي شيء آخر
اذكر، تطبيقًا تلو الآخر: الإصدار الذي يعمل فعلًا، ومدير العمليات، وصورة الأساس، والاعتماديات الأصلية — node-gyp وsharp وbetter-sqlite3. هي التي تحدّد الجدول الزمني، لا شيفرتك: فوحدة مُصرَّفة دون ملف تنفيذي جاهز للإصدار الجديد تعطّل عملية التبديل بأكملها.
اختيار الإصدار المستهدف
دخل Node.js 24 مرحلة Active LTS في 28 أكتوبر 2025، وحُدِّدت نهاية دعمه في 30 أبريل 2028: وهو الهدف الافتراضي. أما Node.js 22، وهو في Maintenance LTS منذ 21 أكتوبر 2025، فمدعوم حتى 30 أبريل 2027 — محطة وسيطة مقبولة إن كانت إحدى الاعتماديات الأصلية غير جاهزة بعد، لا وجهة نهائية. وNode.js 26 لا يدخل مرحلة LTS إلا في 28 أكتوبر 2026: ليس للإنتاج اليوم.
إعادة تشغيل مجموعة الاختبارات على الإصدار المستهدف
أضف الإصدار المستهدف إلى مصفوفة CI قبل إزالة القديم: يجب أن ينجح الاثنان في الوقت نفسه. أعد التثبيت من الصفر (rm -rf node_modules ثم npm ci) لإجبار الوحدات الأصلية على إعادة التصريف — فهناك تظهر الأعطال، نادرًا في اختبارات الوحدة. واقرأ أيضًا تحذيرات الإهمال: فهي أخطاء الإصدار التالي.
تبديل خدمة واحدة في كل مرة
يثبّت nvm install 24 الإصدار الجديد إلى جانب القديم دون إزالته. ثم أعد تشغيل خفيّ مدير العمليات (pm2 update) وأعد إنشاء الخدمة (pm2 delete ثم pm2 start): فالأمر pm2 restart وحده يحتفظ بالمفسّر المسجَّل. أعد توليد سكربت الإقلاع (pm2 startup وpm2 save) وتحقّق عبر pm2 jsonlist من أن الإصدار المُبلَّغ عنه تغيّر فعلًا.
المراقبة ثم التنظيف
أبقِ سجلات الأخطاء ومنحنى الذاكرة تحت نظرك 48 ساعة: فتغيير إصدار V8 يزيح ملمح جامع المهملات أكثر مما يكسر واجهة برمجية. وبعد تأكيد التبديل، أزل Node.js 20 كي لا يعيده أي نشر بالخطأ. وإن فضّلت الانطلاق من خادم نظيف بدل الترحيل في المكان، فدليلنا deployer-nodejs-vps يغطي السلسلة كاملة.
ثبّت الإصدار، لا أن ترحّله فحسب
ترقية وقت التشغيل هي اللحظة المناسبة لإحكام ما يحيط بها. ثبّت الإصدار المستهدف في ملف .nvmrc مُدار مع الشيفرة، ووحّده مع حقل engines في package.json: عندئذٍ يتوقف الخادم وCI وأجهزة المطورين عن التباعد في صمت — وهذا التباعد هو ما يجعل وقت تشغيل منتهي الدعم ينجو من ترحيله. شغّل التطبيق بمستخدم مخصّص، دون صلاحية الكتابة في مجلد شيفرته.
اجعل نهاية الدعم موعدًا مُقرَّرًا لا مفاجأة
جدول Node.js معلن: يصبح الإصدار ذو الرقم الزوجي LTS في أكتوبر، ثم يتوقف بعد ثلاثين شهرًا، دائمًا في 30 أبريل. سيتوقف Node.js 22 في 30 أبريل 2027، وNode.js 24 في 30 أبريل 2028: ويمكن إدراج الموعدين في تقويم التشغيل لديك منذ اليوم. فترقية الإصدار، إذا عوملت كمهمة دورية مُدرجة في الميزانية، تستغرق أيامًا قليلة في السنة؛ أما إذا فُرضت في ظرف طارئ فتكلفتها أكبر بكثير.
