منذ 4 أغسطس 2026، تفعّل Cloudflare توافق Node.js افتراضياً لأي Worker يستخدم compatibility_date يساوي 2026-08-04 أو تاريخاً أحدث. لا تحتاج المشاريع الجديدة إلى إضافة nodejs_compat أو nodejs_compat_v2. أما المشاريع ذات التاريخ الأقدم فلا يتغير سلوكها تلقائياً، ويمكنها الاستمرار كما هي أو تفعيل التوافق بالـ flags المعروفة.
الخبر يبدو تبسيطاً في الإعداد، لكنه في مشروع قائم يعني أن تحديث التاريخ صار تغيير runtime حقيقياً. قد تبدأ حزمة npm بالعمل بعد أن كانت تفشل عند import، وقد يتحول stub إلى implementation جزئي، وقد يتغير bundle أو startup أو مسار الخطأ. لذلك لا ترفع compatibility_date في production مع تحديث dependencies وإعادة تصميم الكود في commit واحد.
إعلان Cloudflare في 4 أغسطس 2026 ومرجع توافق Node.js الحالي
ما معنى enabled by default فعلياً؟
توفر Workers واجهات Node بطريقتين. بعضها implementation أصلي داخل runtime، وبعضها polyfill أو stub يضيفه Wrangler كي ينجح import لكن يرمي خطأ عند استدعاء وظيفة غير مدعومة. جدول Cloudflare الحالي يضع مثلاً Buffer وCrypto وEvents وFile System ضمن الدعم الأصلي، بينما Console وDNS ودوال أخرى موصوفة بأنها جزئية.
هذا مهم عند تقييم حزمة npm. نجاح build أو import ليس إثبات توافق. قد تستخدم الحزمة فرعاً لا يعمل إلا وقت اتصال شبكة أو قراءة ملف أو بدء stream. اقرأ supported API table، ثم اختبر وظائف الحزمة التي يستعملها المنتج فعلاً تحت runtime الخاص بـ Workers.
الإعداد الجديد لمشروع بتاريخ حديث بسيط:
{
"name": "customer-api",
"main": "src/index.ts",
"compatibility_date": "2026-08-29"
}لا تضف flag موجباً بلا حاجة. وإذا كان لديك سبب موثق لإيقاف طبقتي التوافق مع تاريخ حديث، تطلب Cloudflare إضافة no_nodejs_compat وno_nodejs_compat_v2 معاً. اجعل ذلك قراراً مؤقتاً له owner واختبار وتاريخ مراجعة، لا إعداداً غامضاً يبقى سنوات.
compatibility_date عقد تشغيل لا حقل صيانة
تستخدم Cloudflare التاريخ لتمكين تغييرات runtime غير المتوافقة حتى ذلك اليوم. الهدف أن تبقى Workers المنشورة مستقرة بينما تختار المشاريع متى تدخل السلوك الجديد. تقول الوثائق إن التاريخ القديم مدعوم، لكن البقاء عليه دائماً يبعد المشروع عن APIs والإصلاحات الحالية ويجعل الوثائق الحديثة أقل تطابقاً مع الواقع الذي تشغله.
عند رفع التاريخ، راجع كل compatibility flags بين التاريخين، لا إعلان Node.js وحده. التاريخ الجديد يأخذ أثره عند النشر التالي بـ Wrangler. افصل هذه الخطوة في release واضح:
- ثبّت نسخة dependencies وWrangler وبيئة البناء.
- غيّر التاريخ فقط في branch مخصص.
- شغّل unit وintegration والاختبارات العقدية.
- قارن bundle size وstartup وCPU والأخطاء.
- انشر version أو بيئة staging ثم traffic محدوداً.
- احتفظ بنسخة Worker السابقة وخطة rollback.
الهدف ليس إثبات أن endpoint يعيد 200، بل أن المصادقة والـ streams والوقت والـ crypto والاتصالات وسلوك الأخطاء بقيت صحيحة.
حزم npm: اختبر الواجهة لا اسم الحزمة
يقلل التوافق الجديد الحاجة إلى forks وpolyfills، خصوصاً للحزم التي تعتمد على node:crypto, node:buffer, node:stream, node:net, node:dns, node:fs وnode:http. لكنه لا يجعل Workers سيرفر Node تقليدياً ولا يوفر نظام تشغيل دائم.
خذ node:fs مثالاً. توفر Workers virtual file system بقراءة ملفات /bundle وكتابة مؤقتة في /tmp. محتوى /tmp خاص بالطلب وغير دائم ولا يظهر لطلب تال. الملفات المؤقتة في الذاكرة وتدخل ضمن حد Worker البالغ 128 MB، وبعض APIs مثل watch وglob غير منفذة، وtimestamps حالياً تعود إلى Unix epoch. حزمة تتوقع قرصاً دائماً أو permissions POSIX قد تبني بنجاح ثم تنتج بيانات مفقودة.
أنشئ مصفوفة لكل dependency حساسة:
| السؤال | دليل القبول |
|---|---|
| ما وحدات Node المستوردة؟ | dependency trace أو bundle report |
| هل الدعم أصلي أم جزئي أم stub؟ | جدول Cloudflare المؤرخ |
| ما المسار المستخدم في الإنتاج؟ | integration test للتدفق الحقيقي |
| هل تكتب ملفات أو تفتح sockets؟ | اختبار limits والفشل وإعادة المحاولة |
| هل تعمل في 128 MB وCPU الخطة؟ | قياس staging وproduction canary |
لا تعتمد على قائمة compatibility في README للحزمة وحدها. قد تكون اختبرت إصداراً أقدم من Workers أو مساراً مختلفاً عن استخدامك.
أثر التكلفة والأعمال
لا تعرض Cloudflare سعراً منفصلاً لتفعيل Node.js compatibility. الفاتورة تظل فاتورة Workers وفق الطلبات وCPU والمنتجات المرتبطة. في 29 أغسطس 2026، الخطة المجانية تتضمن 100,000 طلب يومياً و10 ms CPU لكل invocation. Workers Paid يبدأ بحد أدنى 5 دولارات شهرياً للحساب، ويتضمن 10 ملايين طلب و30 مليون CPU ms شهرياً، ثم 0.30 دولار لكل مليون طلب إضافي و0.02 دولار لكل مليون CPU ms إضافي. حسابات Enterprise تخضع للعقد.
التوافق قد يغير الكلفة بشكل غير مباشر. حزمة npm كبيرة قد تزيد startup أو CPU، وpolyfill قد ينفذ عملاً أكثر من API Web أصلية، وكتابة ملفات مؤقتة قد تضغط حد الذاكرة. وفي المقابل، إزالة adapters مخصصة قد تقلل الصيانة والأخطاء. قارن تكلفة الطلب الناجح قبل وبعد، بما فيها retries وcold behavior، ولا تحوّل تبسيط config إلى وعد تلقائي بالتوفير.
للأعمال، القيمة الأساسية هي توسيع اختيار المكتبات وتقليل كود التوافق. هذا يسرع تسليم APIs صغيرة وmiddleware ومعالجة محتوى، لكنه لا يلغي فحص data residency أو secrets أو قاعدة البيانات أو vendor lock-in. قرار نقل خدمة من Node server إلى Workers يجب أن يبقى مبنياً على workload، لا على أن imports أصبحت تعمل.
بوابة ترحيل عملية
جرد الإعداد الحالي
سجل التاريخ والflags لكل environment. ابحث عن اختلافات بين wrangler.jsonc, wrangler.toml, dashboard وCI. تحقق من أن preview وproduction يستخدمان نفس الإعداد المقصود.
راجع السلوك بين التاريخين
افتح صفحة compatibility flags واحصر كل flag أصبح افتراضياً. صنف كل واحد: غير مستخدم، يحتاج اختباراً، أو يمنع الترقية. لا تخفِ التعارض بإضافة flags سالبة من دون issue وخطة إزالة.
اختبر حالات الفشل
اختبر timeout وDNS failure وstream cancellation وcrypto input غير صالح وملف أكبر من المتوقع. تحقق من error types والرسائل التي تعتمد عليها المراقبة. أعد تشغيل نفس الاختبارات محلياً وعلى نسخة Cloudflare لأن profile المحلي لا يمثل CPU المنصة بالكامل.
انشر تدريجياً
انشر version ثابتة، ثم راقب 5xx وCPU وstartup وlatency وحجم bundle. نفذ synthetic requests للتدفقات الحساسة. إذا ارتفع الخطأ أو تغير output، أعد traffic للنسخة السابقة ثم حل السبب خارج production.
حدود التوافق والتوفر
- التغيير عام على Workers Free وPaid التي تستخدم تاريخ 2026-08-04 أو أحدث، ولا تعرض الوثائق قيد دولة أو منطقة لهذه الميزة. خطة Enterprise قد تحتوي شروطاً مختلفة يجب قراءتها من العقد.
- الدعم هو subset من Node.js، وبعض APIs جزئية أو مجرد stubs. راجع الجدول الحالي لكل وحدة.
- حدود Workers ما زالت قائمة: 128 MB ذاكرة، وحدود CPU وsubrequests وحجم script حسب الخطة.
node:fsافتراضي وليس تخزيناً دائماً. استخدم KV أو D1 أو R2 أو Durable Objects حسب نموذج البيانات بدلاً من الاعتماد على/tmp.- الترقية إلى تاريخ حديث قد تفعّل تغييرات أخرى غير Node compatibility.
- المشاريع بتاريخ 2026-08-03 أو أقدم لا تتغير تلقائياً، ويمكنها تفعيل
nodejs_compatيدوياً.
توصية عملية
للمشروع الجديد، ابدأ بتاريخ اليوم ومن دون flags موجبة زائدة، ثم اختبر كل dependency تحت Workers runtime. للمشروع القديم، اجعل ترقية التاريخ release مستقلة تملك مقارنة واضحة وخطة رجوع. لا تؤجلها بلا نهاية، ولا تجمعها مع إعادة بناء كبيرة تجعل سبب أي تراجع مجهولاً.
عند بناء API أو موقع على Cloudflare، أفضل نتيجة ليست تشغيل مكتبة Node بأي ثمن. الأفضل اختيار أصغر طبقة تؤدي المهمة، استخدام Web APIs الأصلية عندما تكون أوضح، والاستفادة من Node compatibility عندما تقلل مخاطر الصيانة وتنجح تحت limits الفعلية.
المصادر وتاريخ المراجعة
- تفعيل توافق Node.js افتراضياً، 4 أغسطس 2026
- مرجع APIs المدعومة والجزئية
- سياسة compatibility dates
- سلوك node:fs ونظام الملفات الافتراضي
- أسعار وحدود Workers الحالية
- تمت مراجعة الحالة والأسعار والتوفر والحدود في 29 أغسطس 2026.