WebKit يعيد كتابة محمّل الـ modules في Safari لإصلاح top-level await
أخطاء غريبة ظهرت في Safari وحده سنوات كان سببها قرارًا معماريًا بُني على مواصفة متروكة منذ 2016، لا كود المطورين.
نشر فريق WebKit في 2 سبتمبر 2026 مقالًا بقلم Kai Tamkun بعنوان “Fixing Top-Level Await in Safari”، يشرح كيف أُصلح دعم top-level await في المتصفح. وtop-level await هو إمكانية استخدام await في المستوى الأعلى من الـ module، خارج أي دالة.
وأصل المشكلة أقدم من الميزة نفسها. فمحمّل الـ modules في Safari كان مبنيًا على مقترح اسمه WHATWG Loader، آخر تحديث له في يناير 2016. أي أن المحمّل بُني على مواصفة توقف تطويرها، ثم أضافت ECMAScript 2022 ميزة top-level await التي لم تكن تلك المواصفة تعرفها.
وكانت النتيجة أخطاء غريبة الشكل. فعند استيراد الـ module نفسه عدة مرات وهو يحتوي على top-level await، كان Safari يعيد الاستيرادات بترتيب خاطئ. وكان يرمي خطأ يفيد بأن الـ export قُرئ قبل تهيئته، رغم أنه كان جاهزًا فعلًا وقت القراءة.
والسبب أن المحمّل القديم كان يحسم وعد الاستيراد مبكرًا، قبل أن ينتهي تنفيذ الـ module الذي ينتظر await.
ولم يكن الحل رقعة صغيرة. فقد أعاد الفريق كتابة المحمّل كاملًا بلغة C++ بين يناير ومنتصف 2026، بترجمة شبه حرفية للـ pseudocode الوارد في المواصفة، بدل النسخة القديمة المكتوبة بـ JavaScript. واختُبر بحالات مأخوذة من Bun، وبـ fuzzing لرسوم modules معقدة، وبمجموعتي test262 وWPT.
ويصل الإصلاح في Safari 27، وهو متاح الآن في Safari Technology Preview 251.
وبالنسبة لفرق الويب، قد تتحول الحلول الالتفافية التي أُضيفت سابقًا لتجنب هذه الأخطاء إلى عبء زائد في الكود بعد انتشار Safari 27، لا إلى حماية.