لو لسه شغّال على 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)

1. اعرف إصدارك الحالي:
   Bashنسخ الكود

   node --version
   npm --version

2. ثبّت nvm لو ما عندكش:
   Bashنسخ الكود

   curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.0/install.sh | bash
   source ~/.bashrc

3. ثبّت Node 24 LTS:
   Bashنسخ الكود

   nvm install 24 --lts
   nvm use 24
   node --version  # v24.15.0
   npm --version   # 11.x.x

4. حدّث package.json:
   JSONنسخ الكود

   {
     "engines": {
       "node": ">=24.0.0",
       "npm": ">=11.0.0"
     }
   }

5. شغّل كل الـ tests نظيف:
   Bashنسخ الكود

   rm -rf node_modules package-lock.json
   npm install
   npm test
   npm audit

6. حدّث CI/CD والـ Dockerfile:
   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 ولا حاجة تانية.

المصادر

• Node.js v24.0.0 Release Notes (nodejs.org)
• Node.js Release Schedule (nodejs.org)
• Node.js End of Life Dates (endoflife.date)
• TC39 Explicit Resource Management Proposal
• npm 11 CLI Documentation