أعادت Cloudflare كتابة سجل الوحدات في المكوّن مفتوح المصدر workerd، وهو المكوّن الأساسي لبيئة تشغيل Workers، بهدف تحسين السرعة والامتثال للمعايير وتقريب طريقة تحميل الوحدات وحلّها من سلوك Node.js. ويأتي ذلك بالتزامن مع تفعيل واجهات Node.js المستقرة افتراضياً في Workers، وإتاحة نشر تطبيقات يصل حجمها إلى 64 ميبيبايت على جميع الخطط، بعد إزالة حد حجم الحزمة المضغوطة.
لكن التغيير الأهم لا يتعلق بعدد واجهات البرمجة المتاحة فقط. فتطبيقات Node.js تعتمد أيضاً على الطريقة التي يحدد بها وقت التشغيل الوحدات، ويحملها، ويخزنها مؤقتاً. وهذا يشمل وحدات ESM وCommonJS وWebAssembly، وهي مسؤوليات يتولاها سجل الوحدات داخل workerd.
ما الذي تغير في السجل الجديد؟
يمكن للمطورين تجربة التنفيذ الجديد بإضافة العلم new_module_registry إلى إعدادات Worker. وعند تفعيله، يدعم Workers كلاً من import.meta.url وimport.meta.main وimport.meta.resolve()، كما يتعامل مع محددات الوحدات باعتبارها عناوين URL حقيقية، بما في ذلك سلاسل الاستعلام وأجزاء العنوان.
عملياً، يعني ذلك أن الواردات النسبية تتبع قواعد new URL() نفسها، وأن العناوين الكاملة يمكن استخدامها كمحددات للوحدات. كما تصبح الوحدات التي تختلف في سلسلة الاستعلام أو الجزء اللاحق من العنوان وحدات مستقلة، حتى لو أشارت إلى المصدر نفسه. لذلك يمكن أن تمتلك نسختان من الملف ذاته حالة عليا منفصلة، بينما يعيد استخدام المحدد نفسه النسخة ذاتها من الوحدة.
يدعم السجل أيضاً التحقق الصحيح من سمات الاستيراد. نوع json هو النوع المتاح حالياً، في حين تُعرّف أنواع مثل text وbytes لكنها تُرفض برسالة واضحة لأنها لم تُفعّل بعد. كذلك لم تعد السمات غير المعروفة تُتجاهل بصمت، بل تؤدي إلى خطأ صريح.
توافق أكبر مع Node.js
يتبع require() عند تحميل وحدة ESM قواعد Node.js الخاصة بـ require(esm). فإذا صدّرت الوحدة قيمة باسم module.exports تُعاد تلك القيمة، وإلا يعيد الاستدعاء كائن مساحة أسماء الوحدة. ويستثنى من ذلك مكوّنات node: المدمجة في workerd، إذ تعيد واجهة CommonJS المتوقعة بدلاً من إجبار المطور على الوصول إلى خاصية default.
هناك قيد مهم: لا يستطيع require() تحميل وحدة تحتوي، أو تعتمد على وحدة تحتوي، على top-level await، لأن require يجب أن يعيد النتيجة بشكل متزامن. في هذه الحالة يطرح Workers خطأ، ويكون import() غير المتزامن هو المسار المناسب. وتظل هذه القاعدة قائمة حتى لو جرى تحميل الوحدة نفسها مسبقاً عبر import().
كما توحّد النسخة الجديدة فئات الأخطاء وصياغة رسائلها بغض النظر عن طريقة التحميل، سواء عبر import ثابت أو import() ديناميكي أو require(). ففشل العثور على الوحدة يعيد خطأً عادياً، بينما يؤدي محدد لا يمكن تحليله كعنوان URL إلى TypeError. وتفيد هذه الاستمرارية المطورين الذين يبنون محمّلات مخصصة أو منطقاً لإعادة المحاولة.
ما الذي يتغير عملياً للمطورين؟
كانت أدوات Workers، مثل Wrangler، تجمع معظم ملفات التطبيق والاعتماديات في وحدة واحدة باستخدام esbuild، ما يقلل حجم الرسم البياني الذي يعالجه وقت التشغيل. أما استخدام Cloudflare Vite plugin، فيعتمد في Vite 8 على Rolldown لإنتاج وحدة إدخال ووحدات إضافية عند تقسيم الشيفرة، مثل الوحدات المحمّلة ديناميكياً.
يفتح السجل الجديد المجال أمام أدوات التجميع لإجراء تحويلات أقل والاعتماد بدرجة أكبر على وقت التشغيل في حل الوحدات. وهذا مهم خصوصاً عند نشر التطبيقات كعدة وحدات، أو استخدام خيار --no-bundle، أو التعامل مع ملفات Wasm والنصوص والملفات الثنائية كملفات مستقلة بدلاً من تضمينها داخل حزمة واحدة.
كما يؤجل التنفيذ الجديد عملية الترجمة إلى أن تُستورد الوحدة لأول مرة، سواء باستيراد ثابت أو ديناميكي، ويتيح مشاركة ذاكرات التخزين المؤقت للشيفرة بين نسخ V8 isolate المتعددة التي تشغّل Worker نفسه. ووفق Cloudflare، يعالج ذلك جانباً من الترجمة المتكررة ووجود نسخ متعددة من المصدر في الذاكرة ضمن التنفيذ السابق.
الحدود وما ينبغي الانتباه إليه
رغم هذه التغييرات، لن يتفعّل السجل الجديد تلقائياً لأي Worker، قديم أو جديد، بغض النظر عن تاريخ التوافق المستخدم. يجب إضافة العلم صراحة، كما أن Cloudflare أبقت التنفيذ السابق قيد الاستخدام، وتقول إن Workers المنشورة ستواصل العمل كما كانت.
يدعم التنفيذ الجديد أيضاً استيراد مرحلة المصدر لوحدات WebAssembly، بما يعيد كائن WebAssembly.Module مباشرة، لكن هذه الميزة تعمل حالياً مع WebAssembly فقط، وأي نوع آخر يؤدي إلى خطأ نحوي. لذلك لا يمثل التحديث انتقالاً شاملاً لكل مسارات تحميل الوحدات دون قيود، بل يقدّم أساساً أكثر توافقاً يمكن للمطور اختباره تدريجياً.
القراءة التحريرية: القيمة الفعلية للتغيير تكمن في نقل Workers من محاكاة جزئية لسلوك الوحدات إلى نموذج أقرب إلى معايير JavaScript وNode.js، وهو ما قد يقلل التحويلات التي تفرضها أدوات البناء ويجعل التطبيقات متعددة الوحدات أكثر قابلية للنقل. لكن أثره النهائي سيعتمد على اختبار المطورين للعلم الجديد، خصوصاً مع الاعتماديات التي تستخدم require() أو top-level await أو سمات الاستيراد. كما أن عدم تفعيله افتراضياً يعني أن التوافق المحسن لا يصبح بعدُ السلوك العام لجميع التطبيقات.
كيف أعددنا هذا الخبر؟
اعتمد الخبر على المصدر الأصلي الموضح أعلاه. قد نستخدم أدوات آلية للمساعدة في الاستخراج والتصنيف والصياغة،
لكن النشر يخضع لقواعد تمنع المحتوى المكرر والقصير أو الروتيني منخفض القيمة.
اقرأ سياستنا التحريرية.