مسرد المصطلحات

هذه الصفحة تجمع المصطلحات الشائعة في منظومة webpack وتشرحها باختصار.

A

• Asset: مصطلح عام يشير إلى الصور، والخطوط، والوسائط، وأي ملفات أخرى تُستخدم عادةً في المواقع والتطبيقات. غالبًا تنتهي هذه الملفات كملفات مستقلة داخل output، ويمكن أيضًا تضمينها مباشرة عبر أدوات مثل style-loader أو url-loader.

B

• Bundle: ملف ناتج من عدة modules منفصلة. يحتوي bundle على النسخ النهائية من ملفات المصدر بعد مرورها بمرحلة loading وcompilation.
• Bundle Splitting: طريقة لتحسين عملية build عبر جعل webpack ينتج عدة bundles لتطبيق واحد. هذا يجعل كل bundle أكثر استقلالًا عن تغييرات bundles الأخرى، فيقل حجم الكود الذي يحتاج إلى نشره أو تنزيله مرة أخرى من جهة المستخدم، وتستفيد أكثر من browser caching.

C

• Chunk: مصطلح خاص بـ webpack يُستخدم داخليًا لإدارة عملية bundling. تتكون bundles من chunks، ولها عدة أنواع مثل entry وchild. غالبًا تتطابق chunks مباشرةً مع bundles الناتجة، لكن بعض الإعدادات لا تعطي علاقة واحد إلى واحد.
• Code Splitting: تقسيم الكود إلى عدة bundles أو chunks يمكن تحميلها عند الحاجة بدل تحميل bundle واحد يحتوي على كل شيء.
• Configuration: ملف إعدادات webpack هو ملف JavaScript عادي يصدّر object. يعالج webpack هذا object بناءً على الخصائص التي عرّفتها فيه.

D

• Dependency Graph: عندما يعتمد ملف على ملف آخر، يتعامل webpack مع ذلك كـ dependency. يبدأ webpack من entry point أو أكثر، ثم يبني dependency graph بشكل متكرر ليشمل كل module وasset يحتاجه تطبيقك.

E

• Entry Point: يحدد entry point المكان الذي يبدأ منه webpack، ثم يتبع graph الخاص بالاعتمادات لمعرفة ما الذي يجب تضمينه في bundle. يمكنك اعتباره الجذر السياقي لما تريد تحزيمه.

H

• Hot Module Replacement (HMR): عملية تبدّل أو تضيف أو تزيل modules أثناء تشغيل التطبيق، بدون إعادة تحميل الصفحة بالكامل.

L

• Loaders: تحويلات تُطبّق على كود المصدر الخاص بـ module. تسمح لك بمعالجة الملفات مسبقًا أثناء استخدام require() أو أثناء "تحميلها". يمكن التفكير فيها بشكل قريب من أدوات task-runner.
• Lazy Loading: تحميل أجزاء من التطبيق، مثل chunks، بشكل مؤجل. أي لا يتم تحميلها إلا عندما تحتاجها فعلًا.

M

• Module: جزء مستقل من الوظائف، حجمه ونطاقه أصغر من برنامج كامل. الـ modules المكتوبة جيدًا توفر abstractions واضحة وحدود encapsulation تساعد على تصميم منظم ومفهوم.
• Module Resolution: يمكن طلب module كاعتماد من module آخر. أما resolver فهو مكتبة تساعد على العثور على module من خلال مساره المطلق. يبحث webpack عن modules داخل كل المجلدات المحددة في resolve.modules.
• Manifest: يستخدمه runtime لحل modules وتحميلها بعد أن يتم تحزيمها وإرسالها إلى المتصفح.

O

• Output: خيار أو مجموعة خيارات تحدد أين يكتب webpack الملفات الناتجة بعد compilation على القرص.

  ملاحظة: يمكن أن يكون لديك عدة entry points، لكن يتم تحديد إعداد output واحد فقط.

P

• Plugin: كائن JavaScript يحتوي على الخاصية apply. يستدعي webpack compiler هذه الخاصية، فيحصل plugin على إمكانية الوصول إلى دورة حياة compilation كاملة. غالبًا توسّع هذه الحزم سلوك compilation بطريقة ما.

R

• Request: التعبير المستخدم داخل عبارة require أو import. مثلًا في require("./template/" + name + ".ejs") يكون request هو "./template/" + name + ".ejs".

S

• Shimming: ليست كل ملفات JS قابلة للاستخدام مباشرة مع webpack. قد يكون الملف بتنسيق modules غير مدعوم، أو قد لا يستخدم modules أصلًا. هنا يأتي دور shimming.

T

• Target: بيئة النشر التي يحددها المستخدم ليتم compilation لها، مثل المتصفح أو NodeJS أو Electron. القائمة موجودة في صفحة target.
• Tree Shaking: إزالة الكود غير المستخدم، أو بشكل أدق استيراد الكود الحي فقط. يفعل webpack ذلك عبر تحليل أنواع import المختلفة واستخدامات الكود المستورد لمعرفة الأجزاء المستخدمة فعليًا من dependencies، ثم حذف أجزاء "الشجرة" غير اللازمة.

V

• Vendor Entry Point: إنشاء dependency graphs تبدأ من app.js وvendors.js. تكون هذه graphs منفصلة ومستقلة، مما يسمح بالاستفادة من CommonsChunkPlugin واستخراج مراجع vendor من app bundle إلى vendor bundle. يساعد ذلك على تطبيق نمط معروف في webpack باسم long-term vendor-caching.

W

• webpack: أداة bundler قابلة للتخصيص بدرجة عالية لتجميع modules في تطبيقات JavaScript الحديثة.