لو لسه شغّال على Node.js 22 في الإنتاج، الخبر النهارده مش "فيه version جديد". الخبر إن Node 22 مات فعلاً يوم 24 مارس 2026، و Node 24.15.0 LTS نزل 15 أبريل كبديل الرسمي. القرار مش "أهاجر بكرة"، القرار بالظبط: إيه اللي لازم يتعمل هذا الأسبوع، وإيه اللي ينفع يستنى شهر.
Node.js 24.15 LTS: الخبر اللي هيغيّر package.json بتاعك
المشكلة باختصار
Node.js 22 (Jod) وصل End of Life في 24 مارس 2026. معناها بالظبط: مفيش security patches، مفيش bug fixes، ومفيش دعم رسمي من المنظمة. أي ثغرة CVE تطلع بعد التاريخ ده مش هتتعالج على 22 أبدًا. في نفس الوقت، Node.js 24 (Krypton) دخل Active LTS من أكتوبر 2025، وآخر إصدار 24.15.0 نزل 15 أبريل 2026.
الترقية مش حاجة "nice to have" — هي مسألة امتثال أمني لأي مشروع production. شركات التأمين السيبراني وفرق الـ SOC بتعتبر أي runtime على إصدار EOL risk مباشر.
Explicit Resource Management: المفهوم اللي هيغيّر طريقة كتابتك
دي أكبر feature جديدة في Node 24. قبل ما ندخل في التعريف العلمي، خد مثال بسيط جدًا.
تخيّل إنك فتحت صنبور مية في المطبخ علشان تملا كوباية. بعد ما تخلّص، لازم تقفل الصنبور. لو نسيت وسبته مفتوح، المية هتفضل جارية والفاتورة هتعلى، وممكن كمان تغرّق البيت. ده بالظبط اللي بيحصل لمّا تفتح ملف أو connection لقاعدة بيانات ومتقفلهاش — الـ resource بيفضل مفتوح، والـ memory بتزيد، لحد ما الـ process يقع أو الـ DB تقفل connections عليك.
قبل Node 24، كنت بتكتب try/finally كل مرة علشان تفتكر تقفل الـ resource يدويًا:
// الطريقة القديمة — Node 22 وما قبله
import { openSync, closeSync, readFileSync } from 'node:fs';
function readConfig() {
const fd = openSync('./config.json', 'r');
try {
const data = readFileSync(fd, 'utf8');
return JSON.parse(data);
} finally {
closeSync(fd); // لازم تفتكر تقفل — لو نسيت، leak
}
}في Node 24 بقى في كلمة جديدة اسمها using. أي resource عامل implement للـ Symbol.dispose بيتقفل تلقائيًا لمّا يخرج من الـ scope:
// Node 24+ — الطريقة الجديدة
class FileHandle {
constructor(path) {
this.fd = openSync(path, 'r');
}
read() { return readFileSync(this.fd, 'utf8'); }
[Symbol.dispose]() { closeSync(this.fd); }
}
function readConfig() {
using handle = new FileHandle('./config.json');
return JSON.parse(handle.read());
// handle[Symbol.dispose]() بيتنادى تلقائيًا هنا
// حتى لو throw حصل، الـ cleanup مضمون
}التعريف التقني: Explicit Resource Management هو TC39 proposal اتقبل في Stage 4 وبيشتغل عبر V8 13.6 اللي جوّا Node 24. بيضيف كلمتين using و await using، ودول بينادوا [Symbol.dispose]() أو [Symbol.asyncDispose]() على الـ object تلقائيًا لمّا الـ block يخلص — سواء خلص طبيعي أو بـ exception. الفايدة الحقيقية: استحالة تنسى cleanup.
npm 11: أسرع بـ 65% في install
Node 24 بيجي مع npm 11 by default. الأرقام الرسمية من فريق npm:
- install من الصفر (بدون cache): أسرع بـ 65% على متوسط 50 مشروع مختلف.
- install بـ cache موجود: أسرع بـ 40%.
- package-lock.json parsing: أسرع بـ 3× بفضل streaming parser جديد.
- استهلاك الذاكرة أثناء install: أقل بـ 30%.
مثال واقعي: تطبيق Next.js متوسط الحجم فيه 850 dependency. الـ install على Node 22 بياخد 2 دقيقة 40 ثانية. على Node 24 بياخد 54 ثانية. لو بتـ deploy 10 مرات في اليوم، ده بيوفرلك حوالي 18 دقيقة CI يوميًا — حوالي ساعة ونص أسبوعيًا لكل مشروع.
الخطوات الفعلية للترقية (copy-paste)
-
اعرف إصدارك الحالي:
node --version npm --version -
ثبّت nvm لو ما عندكش:
curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.0/install.sh | bash source ~/.bashrc -
ثبّت Node 24 LTS:
nvm install 24 --lts nvm use 24 node --version # v24.15.0 npm --version # 11.x.x -
حدّث
package.json:{ "engines": { "node": ">=24.0.0", "npm": ">=11.0.0" } } -
شغّل كل الـ tests نظيف:
rm -rf node_modules package-lock.json npm install npm test npm audit -
حدّث CI/CD والـ Dockerfile:
FROM node:24-alpine AS builder WORKDIR /app COPY package*.json ./ RUN npm ci --omit=dev COPY . . RUN npm run build FROM node:24-alpine WORKDIR /app COPY --from=builder /app/dist ./dist COPY --from=builder /app/node_modules ./node_modules CMD ["node", "dist/server.js"]
trade-offs حقيقية: بتكسب إيه، بتخسر إيه
الترقية مش كلها ورد. فيه حاجات هتكسرها بالظبط:
- OpenSSL 3.5 بـ default security level 2: أي مفتاح RSA/DSA/DH أقل من 2048 bit مش هيشتغل. أي مفتاح ECC أقل من 224 bit نفس الحكاية. لو عندك legacy certificates، لازم تجددها قبل الترقية.
- RC4 cipher suites انقطعت نهائيًا: لو بتتعامل مع API قديم بيفرض RC4، مش هيتوصل. ده هيضرب أي تكامل مع أنظمة بنكية قديمة جدًا.
- Buffer APIs أصرم: الكتابة خارج طول الـ Buffer بقت بترمي
RangeErrorبدل ما تدي behavior غير محدد. - node-gyp بيتطلب C++17: لو عندك native modules قديمة مبنية على C++14، لازم rebuild أو ترقية للـ package.
- fs.existsSync() بيحذّر على invalid inputs: مش كارثة، لكن هيـ spam الـ logs بتاعتك لو الكود بيمرر null أو undefined.
المكسب بالمقابل: أمان أعلى فعلاً، سرعة install أحسن بنسبة قابلة للقياس، access للـ features زي using و await using و RegExp.escape() و global URLPattern، ودعم رسمي ممتد لغاية أبريل 2028.
متى لا تستخدم هذه الترقية الآن
فيه 3 حالات حقيقية مش تستاهل فيها ترقية مستعجلة:
- لو المشروع بيعتمد على package مش داعم Node 24 بعد. اتأكد بـ
npm ls --allثمnpx is-node-24-ready. لو لقيت dependency حرج مش داعم، استنى update منه الأول. - لو عندك production حرج ومفيش staging مطابق. الترقية في staging الأول لأسبوع على الأقل تحت load حقيقي. أي regression في الـ memory أو CPU هيبان في 72 ساعة.
- لو بتستخدم framework قديم. NestJS < v10 أو Electron < v28 لسه الـ compatibility matrix بتاعتهم متأكد منهاش. جرّب على branch منفصلة الأول.
الافتراضات اللي الشرح ده مبني عليها
الأرقام والخطوات اللي فوق دي مبنية على: مشاريع Node.js server-side (Express, Fastify, NestJS, Next.js) شغّالة على Linux أو macOS، وبتستخدم npm كـ package manager. لو بتستخدم pnpm أو yarn berry، الأرقام هتتغيّر (عادةً pnpm بيكون أقرب للأرقام الجديدة حتى قبل الترقية).
الخطوة التالية
الأسبوع ده: افتح الـ package.json بتاعك وشغّل npx npm-check-updates. لو في dependencies قديمة بتمنع الترقية، ابدأ بتحديثهم الأول. بعد 48 ساعة، جرّب Node 24 على dev environment واركن الـ test suite كامل. لو عدّى نظيف، حدّد weekend للترقية على production مع rollback plan جاهز. لو الـ tests فشلت، ابعتلي output الـ failing tests على البريد وهنشوف هي من الـ API changes ولا حاجة تانية.