منذ بضعة أيام، تلقينا رسالة ذات أولوية في دردشة Teams في مؤسستنا، والتي نصها: تم العثور على ثغرة أمنية - تم اكتشاف Polyfill JavaScript - HIGH.
ولتوضيح الأمر، أنا أعمل في شركة مصرفية كبرى، وكما تعلم، فإن نقاط الضعف المصرفية والأمنية تشبه الأعداء الرئيسيين. لذلك، بدأنا في التعمق في هذه المسألة وتم حلها في غضون ساعات قليلة، وهو ما سأناقشه فيما يلي. لكن الجزء الجيد (أو الأسوأ؟) هو أنه عندما بحثت في Google عن المشكلة في البداية، فإن نتائج البحث التي ظهرت أبقتني مدمن مخدرات لبقية اليوم!

دعونا نسلط الضوء على التناقض بين المتصفح الحديث والمتصفح القديم. فيما يلي مقارنة بين أحدث إصدار من Chrome مقابل Internet Explorer (IE) 9. تدعم المتصفحات الحديثة مجموعة كبيرة من ميزات ES6 وفي نفس الوقت، IE9 وأيضًا IE11، والتي لا تزال تستخدم من قبل الكثير من الشركات بالكاد تدعم أي ميزات ES6 .
هنا يأتي للمساعدة في مفهوم transpiling، والذي يشير في سياق JavaScript إلى تحويل كود المصدر المكتوب بلغة JavaScript الحديثة (ES6/ES2015 وما بعده) إلى إصدار أقدم مثل ES5 ، والذي تدعمه المتصفحات القديمة على نطاق واسع. من أشهر برامج الترجمة هو Babel، والذي يقدم مجموعة من الميزات مثل تحويل بناء الجملة، وتجميع التعليمات البرمجية (مع Webpack) ودعم JSX (لصديقنا العزيز React!).

الآن، يعد استخدام أجهزة النقل أمرًا شائعًا جدًا في الأماكن التي يوجد بها الكثير من بناء الجملة الحديث، ويجب على المرء التأكد من التوافق عبر البيئات المختلفة. لاحظ أن تحويل قاعدة التعليمات البرمجية بالكامل إلى إصدار مختلف يتطلب الكثير من الوقت وأيضًا إعداد عملية إنشاء وتكوين إضافي لأشياء مثل Babel. وغني عن القول أنه، إلى جانب تحويل الميزات النحوية، يتم أيضًا تغطية وظائف واجهة برمجة التطبيقات (API) لتوسيع نفس النسخ المتماثل للميزات في المتصفح القديم.

بالرجوع إلى مرجع Babel، فهو يشكل الكثير من الحزم، ويوفر مكونات إضافية لأنواع مختلفة من الوظائف مثل تحويل فئات ES6، ووظائف الأسهم، وما إلى ذلك إلى كود JS مكافئ. ومن بين ذلك، تقدم أيضًا حزمة "polyfill" الخاصة بها.

Polyfills هي أجزاء من التعليمات البرمجية التي تمكن المتصفحات القديمة من توفير نفس / نفس وظيفة JS تقريبًا، والتي لا توفرها أصلاً، والتي تظهر في إصدارات المتصفح الأحدث. إليك مثال فيديو سريع وتنفيذ بسيط للغاية.

الآن قد يتساءل المرء، ما الفرق بين الناقلات والحشوات المتعددة؟ حسنًا، تركز عمليات polyfills على محاكاة واجهات برمجة التطبيقات (APIs) المحددة المفقودة بدلاً من تغيير قاعدة التعليمات البرمجية بأكملها إلى إصدار قديم صديق للمتصفح يتم تنفيذه بواسطة أجهزة الإرسال. وهذا يسمح باتباع نهج أكثر تفصيلاً وبالطبع يجعله أكثر كفاءة وأداء.

يجب أن يمنحنا هذا خلفية كافية للوصول إلى النقطة التي جعلتني مدمنًا ليوم واحد حتى اللحظة التي أكتب فيها هذا، حول polyfills.

الآن، لدى Babel حزمة تسمى babel/polyfill والتي تتكون من مكتبتين: core-js وregenerator-runtime. في البداية، استيراد هذه الحزمة من شأنه أن يؤدي إلى تفعيل جميع عمليات polyfills.

import '@babel/polyfill';

ولكن جلب كل شيء سواء كان مشروعك سيستخدمها أم لا، وزيادة حجم الحزمة وحقن polyfills على مستوى العالم قد يؤدي إلى تعارضات في الكائنات.
أدى ذلك إلى إهمال الحزمة ويوصي بابل باستخدام مكتبة core-js مباشرة بواسطة
الخطوة 1: تعديل تكوين بابل

{
  "presets": [
    ["@babel/preset-env", {
      "useBuiltIns": "usage",
      "corejs": 3
    }]
  ]
}

الخطوة 2: استيراد ملفات polyfills التي ستستخدمها في مشروعك يدويًا

import "core-js/es/array/includes";
import "core-js/es/promise";

وبالتالي توفير الذاكرة وتقليل التعليمات البرمجية غير الضرورية.

الآن، هذه هي نهاية جزء واحد، لا يتعلق الأمر بذلك في حد ذاته، ولكنه مهم بالتأكيد فيما يتعلق بالمشروع، ومواكبة التغييرات في التبعيات، وخدمة العملاء بتجربة أفضل.

لكن. وهذا ليس كل شيء.

نحن على وشك مناقشة الهجوم الكبير الذي حدث مؤخرًا وهز شبكة الإنترنت بالكامل وجعلهم يبحثون في قاعدة التعليمات البرمجية الخاصة بهم.
ويتضمن الشيء الذي ناقشناه هنا. لذا ترقبوا الجزء الثاني!