اعتباراً من إصدار 2026.2، أصبح فتح مشروع موجود داخل Windows Subsystem for Linux، أو WSL، من داخل IntelliJ IDEA وWebStorm وPhpStorm يقود إلى ما تسميه JetBrains وضع Native. في هذا الوضع يبقى الـ IDE تطبيقاً يعمل على Windows، بينما يتولى وكيل صغير داخل WSL تنفيذ عمليات الملفات والعمليات البرمجية نيابة عنه. وتقول الشركة إن هذا هو المدخل الموصى به حالياً، في حين يظل خيار Remote Development متاحاً من شاشة الترحيب لكنه لم يعد الطريقة المفضلة لفتح مشاريع WSL.
المسألة لا تتعلق بتغيير اسم في واجهة الاستخدام فقط. فدعم مشروع Linux موجود داخل WSL يتطلب من بيئة التطوير الوصول إلى الملفات، وتشغيل الأدوات بالأمسارات الصحيحة، وإدارة المتغيرات البيئية، وتشغيل عمليات البناء والتصحيح والتنميط، مع إبقاء زمن الاستجابة منخفضاً بما يكفي كي تبدو التجربة طبيعية. وتوضح JetBrains أن الطرق السابقة كانت تستخدم معماريات مختلفة بحسب نقطة الدخول، وهو ما أدى إلى تفاوت في الأداء والسلوك بين المنتجات والسيناريوهات.
لماذا لم يعد مسار 9P كافياً؟
في النهج الأقدم، كانت تطبيقات JetBrains على Windows تصل إلى ملفات WSL عبر بروتوكول نظام الملفات 9P، بينما كانت الفئة GeneralCommandLine تتولى تطبيع أوامر التشغيل داخل بيئة Linux. أتاح ذلك تشغيل الـ IDE ضد مشاريع WSL، لكنه نقل جزءاً كبيراً من عمليات القراءة والفهرسة عبر الحدود بين Windows والآلة الافتراضية التي تستضيف WSL.
بحسب JetBrains، ظهرت ثلاث مشكلات رئيسية. أولاً، لا يعرض 9P الروابط الرمزية Linux بشكل صحيح عبر المسار \\wsl$، ما قد يمنع الـ IDE من حل بعض الأشجار أو فهرستها. وتؤثر هذه المشكلة في بيئات تستخدم الروابط الرمزية، مثل مساحات عمل pnpm والبيئات الافتراضية في Python ومستودعات Composer المعتمدة على المسارات. ثانياً، قد يؤدي فحص Microsoft Defender عند الوصول إلى إطالة قراءة ملفات WSL بعشرات الثواني. وثالثاً، يضيف البروتوكول زمناً ملحوظاً إلى العمليات التي تتعامل مع عدد كبير من الملفات الصغيرة، مثل الفهرسة.
كما أن طبقة تنفيذ الأوامر فرضت على مطوري المنصة التعامل مع دلالات خاصة بـ WSL داخل أجزاء مختلفة من قاعدة الشيفرة. وترى JetBrains أن هذا جعل النهج أكثر صعوبة في التوسع والصيانة، بدلاً من أن يكون أساساً موحداً لبيئات العمل غير المحلية.
ما الذي أضافه Remote Development؟
عالج Remote Development المشكلة من الاتجاه المعاكس: ينتقل الـ backend الكامل للـ IDE إلى WSL، بينما يبقى على Windows عميل يعرض الواجهة ويتلقى إدخالات المستخدم. ويتواصل الطرفان عبر بروتوكول JetBrains RD، الذي ينقل نماذج الأحداث وحالة المحرر والمشروع في الاتجاهين. أما العمليات الثقيلة، مثل الفهرسة والتحليل والبناء والتصحيح وعمليات التحكم في الإصدارات، فتجري داخل WSL بالقرب من الملفات.
هذا التصميم أزال الاعتماد المباشر على 9P للوصول إلى الملفات، لكنه أضاف كلفة أخرى. تقول JetBrains إن الـ backend يحتاج إلى نحو 2 غيغابايت إضافية من مساحة القرص، فضلاً عن وقت تنزيله وتثبيته داخل WSL. كما أن التفاعل المستمر بين العميل والbackend يفرض حركة دائمة لحالة الواجهة وإدخالات المستخدم، وقد ينعكس ذلك على الاستجابة. ويحتاج تطوير المنتج نفسه إلى فصل أجزاء الشيفرة بين العميل والخادم، ما قد يسبب تأخيرات أو تجمدات في الواجهات الديناميكية إذا بقيت بعض الوحدات غير مقسمة.
كيف يعمل Native mode؟
يعتمد النهج الجديد على وكيل يسمى IJent. ينفذ الوكيل عمليات الملفات والعمليات البرمجية داخل البيئة المستهدفة، بدلاً من تمريرها عبر 9P أو طبقات تنفيذ عامة. وتصفه JetBrains بأنه مكوّن صغير مكتوب بلغة Rust، ما يقلل الحاجة إلى اعتماديات تشغيل إضافية مثل Java أو Kotlin داخل WSL أو الحاويات.
يستخدم IJent طبقة نقل تعتمد على Stdio، وهي قابلة للنقل ولا تتطلب فتح منافذ جدار ناري، بينما توفر Hyper-V sockets في WSL مساراً أسرع، خصوصاً عند نقل أعداد كبيرة من الملفات. وبما أن عمليات نظام الملفات تنفذ داخل البيئة Linux نفسها، تصبح معالجة المسارات والروابط الرمزية أقرب إلى دلالات Linux الأصلية. وتستفيد الإضافات الخارجية من ذلك أيضاً عندما تمر عمليات الملفات التابعة لها عبر IJent.
ويرتبط IJent بواجهة EelApi، التي صممتها JetBrains لإخفاء الفارق بين البيئات المحلية والبعيدة أمام مطوري المنصة وكتّاب الإضافات. ووفق هذا النموذج، يمكن للكود نفسه التعامل مع بيئة محلية أو WSL أو Docker أو Dev Container من دون إضافة منطق خاص بكل بيئة. وتقول الشركة إن IJent يطبق واجهة EelApi ويوفر وظائفها الفعلية.
ماذا تقول الاختبارات؟
قارنت JetBrains بين وضع 9P ووضع IJent في اختبار فتح بارد لمشروع spring-framework يضم 23 مشروعاً فرعياً و8,191 ملفاً مصدره. أجريت القياسات على Windows 11 مع WSL 2 وUbuntu 24.04 ونسخة IntelliJ IDEA Ultimate 263.SNAPSHOT، واعتمدت النتائج الوسيط لخمس تشغيلات.
- الاستعداد للعمل: انخفض الزمن من 18.5 ثانية إلى 11.5 ثانية، بتحسن نسبته 38%.
- فحص شجرة المشروع: انخفض من 8.1 ثوانٍ إلى 3.7 ثوانٍ، أي 54% أقل.
- فهرسة الملفات: انخفض من 10.8 ثوانٍ إلى 8.4 ثوانٍ، بتحسن 22%.
- قراءة محتوى الملفات: انخفض من 12.2 ثانية إلى 5.7 ثوانٍ، أي 53% أقل.
وتنبه الشركة إلى أن مشروعاً صغيراً يضم عدداً قليلاً من الملفات لم يظهر فرقاً قابلاً للقياس في الاختبار نفسه. لذلك فإن المكسب العملي الأكبر يخص المشاريع الكبيرة أو سير العمل الذي يتكرر فيه الوصول إلى عدد كبير من الملفات.
ما الذي يعنيه ذلك للمطورين؟
التغيير الأهم هو توحيد نقطة الدخول والمعمارية الموصى بها، لا إلغاء كل الخيارات السابقة فوراً. المستخدم الذي يفتح مشروع WSL مباشرة في المنتجات المدعومة يحصل على Native mode، بينما يبقى Remote Development مفيداً لمن يختار هذا المسار أو يحتاج إلى نموذج العميل والbackend المنفصلين. أما تشغيل الـ IDE نفسه عبر WSLg، فتقول JetBrains إنه ممكن تقنياً لكنه ليس سير عمل مدعوماً من الدرجة الأولى، بسبب قيود مرتبطة بالرسم وإدارة النوافذ والإدخال واعتماد التطبيق على طبقة عرض Linux داخل Windows.
وتشير النتائج المنشورة إلى تحسن ملموس في بعض العمليات، لكن نطاق الاختبار محدود بمشروع وبيئة ونسخة محددة. لذلك لا تثبت الأرقام تفوقاً ثابتاً لكل المشاريع أو الإضافات. كما أن تبني المعمارية الجديدة عبر مزيد من منتجات JetBrains ما زال جارياً، ما يجعل توافق الإضافات وسلوكها في البيئات المختلفة نقطة تستحق المتابعة.
كيف أعددنا هذا الخبر؟
اعتمد الخبر على المصدر الأصلي الموضح أعلاه. قد نستخدم أدوات آلية للمساعدة في الاستخراج والتصنيف والصياغة،
لكن النشر يخضع لقواعد تمنع المحتوى المكرر والقصير أو الروتيني منخفض القيمة.
اقرأ سياستنا التحريرية.