أساسيات إدارة الحزم في تطوير الويب من طرف العميل

سنلقي في هذا المقال نظرة على مدير الحزم Package Manager بشيء من التفصيل لفهم كيفية استخدامه في مشاريعنا لتثبيت اعتماديات Dependencies أدوات المشروع وتحديثها وغير ذلك.

المتطلبات الأساسية: الإلمام بأساسيات لغات HTML وCSS وجافاسكربت.
الهدف: فهم مدراء ومستودعات الحزم، وسبب حاجتنا لها، وأساسيات استخدامها.

اعتماديات المشروع

تعدّ الاعتمادية Dependency جزءًا من برنامج تابع لجهة خارجية كتبه شخص ما غيرك لحل مشكلة نيابة عنك. يمكن أن يحتوي مشروع الويب على أي عدد من الاعتماديات، تتراوح من لا شيء إلى اعتماديات متعددة، ويمكن أن تتضمن اعتمادياتك اعتماديات فرعية لم تثبّتها صراحة، إذ يمكن لاعتمادياتك أن يكون لها اعتمادياتها الخاصة.

من الأمثلة البسيطة على الاعتماديات المفيدة التي يمكن أن يحتاجها مشروعك الشيفرة البرمجية لحساب التواريخ النسبية بوصفها نصًا قابلًا للقراءة. يمكنك بالتأكيد كتابة هذه الشيفرة بنفسك، ولكن يمكن أن يحل شخص آخر هذه المشكلة بدلًا عنك، فلا داعي لنضيع الوقت في إعادة كتابة هذه الشيفرة (ليس علينا إعادة اختراع العجلة). يُحتمَل اختبار اعتمادية موثوقة لطرف ثالث في مواقف متعددة مختلفة، مما يجعلها أقوى وأكثر توافقًا من حلك مع المتصفحات.

يمكن أن تكون اعتمادية المشروع عبارة عن مكتبة أو إطار عمل جافاسكربت كامل مثل React وVue أو أداة مساعدة صغيرة جدًا مثل مكتبة التاريخ القابلة للقراءة، أو يمكن أن تكون أداة سطر أوامر مثل Prettier أو Eslint التي تحدثنا عنها في المقال السابق.

إن لم نستخدم أدوات البناء الحديثة، فيمكن تضمَّين مثل هذه الاعتماديات في مشروعك باستخدام عنصر <script> بسيط، ولكن يمكن ألا تعمل هذه الطريقة مباشرة، وبالتالي ستحتاج بعض الأدوات الحديثة لتجميع الشيفرة والاعتماديات مع بعضها بعضًا عند إصدارها على الويب. الحزمة Bundle هي المصطلح المُستخدَم للإشارة إلى ملف على خادم الويب الخاص بك الذي يحتوي على شيفرة جافاسكربت الخاصة ببرنامجك، وتُضغَطُ الحزمة قدر الإمكان للمساعدة في تقليل الوقت الذي يستغرقه تنزيل البرنامج وعرضه في متصفح زوار موقعك.

لا يُعَد تتبّع بعض الاعتماديات أمرًا صعبًا إذا وجدت أداة أفضل تريد استخدامها بدلًا من الأداة الحالية، أو أُصدِر إصدار جديد من الاعتمادية تريد التحديث إليه، ولكن يمكن أن يصبح هذا النوع من الأشياء صعبًا في المشاريع الكبيرة التي تحتوي على اعتماديات متعددة، لذلك يمكنك استخدام مدير حزم Package Manager مثل npm، لأنه سيضمن إضافة الشيفرة وإزالتها بطريقة نظيفة، بالإضافة إلى مجموعة من المزايا الأخرى.

مدير الحزم

مدير الحزم هو نظام يدير اعتماديات مشروعك، ويوفّر طريقة لتثبيت اعتماديات جديدة يُشار إليها باسم "الحزم Packages"، وإدارة مكان تخزين الحزم على نظام ملفاتك، وتقديم إمكانيات لنشرها.

يمكنك تنزيل اعتماديات مشروعك وتخزينها يدويًا دون استخدام مدير حزم، ولكن مدير الحزم سيتعامل بسلاسة مع تثبيت الحزم وإلغاء تثبيتها. إن لم تستخدم مدير حزم، فسيتعين عليك التعامل مع ما يلي يدويًا:

العثور على كافة ملفات جافاسكربت الصحيحة الخاصة بالحزمة.
التحقق منها للتأكد من عدم وجود أي ثغرات أمنية.
تنزيلها ووضعها في الأماكن الصحيحة في مشروعك.
كتابة الشيفرة لتضمين الحزمة أو الحزم في تطبيقك، إذ يمكن تطبيق ذلك باستخدام وحدات جافاسكربت.
تطبيق الخطوات نفسها مع جميع اعتماديات الحزم الفرعية التي يُحتمَل وجود عشرات أو مئات منها.
إزالة جميع الملفات مرة أخرى إذا أردت إزالة الحزم.

كما يتعامل مدير الحزم مع الاعتماديات المكرَّرة، وهو أمر مهم وشائع في تطوير الواجهة الأمامية.

لديك خياران لمكان تثبيت اعتمادياتك في حالة npm ومدير الحزم المستند إلى جافاسكربت وNode، ويمكن تثبيت الاعتماديات بطريقة عامة أي لكل المشاريع أو محليًا في مشروع معين فقط. بالرغم من وجود كثير من إيجابيات التثبيت العام، إلّا أن إيجابيات التثبيت المحلي لكل مشروع مهمة مثل قابلية نقل الشيفرة وقفل الإصدار.

إذا اعتمد مشروعك مثلًا على Webpack مع إعداد معين، فيجب التأكد من عمل هذا الإعداد عند تثبيت المشروع على جهاز آخر أو العودة إليه لاحقًا. إذا ثُبِّت إصدار مختلف من Webpack، فيمكن ألّا يكون متوافقًا، لذلك يجب تثبيت الاعتماديات محليًا في المشروع.

حاول تنزيل وتشغيل مشروع قائم، فإذا نجح وعملت جميع الاعتماديات مباشرة، فعندئذٍ لديك اعتماديات محلية يجب أن تشكرها على حقيقة أن الشيفرة قابلة للنقل.

اقتباس

ملاحظة: ليس npm مدير الحزم الوحيد المتاح، فمدير الحزم البديل الناجح والشائع هو Yarn الذي يثبت الاعتماديات باستخدام خوارزمية مختلفة يمكن أن توفر تجربة مستخدم أسرع. كما يوجد عدد من العملاء الناشئين الآخرين مثل pnpm.

سجلات الحزم Package Registries

يحتاج مدير الحزم ليعمل إلى معرفة المكان الذي نثبّت الحزم منه، وهو ما يدعَى بسجل الحزمة Package Registry. السجل هو مكان مركزي تُنشَر الحزمة عليه وبالتالي يمكن تثبيتها منه. يُعدُّ npm اسم سجل الحزم الأكثر استخدامًا لحزم جافاسكربت.

ليس npm الخيار الوحيد لإدارة سجل حزمتك، إذ تتيح لك منتجات مثل Microsoft Azure إنشاء وكلاء لسجل npm إذ يمكنك تجاوز أو قفل حزم معينة، كما يقدم GitHub خدمة تسجيل حزمة، ويُحتمَل ظهور مزيد من الخيارات مع مرور الوقت. المهم هو التأكد من اختيارك لأفضل سجل مناسب لك، ولكن ستستخدم العديد من المشاريع مدير الحزم npm، وسنستخدمها في أمثلتنا.

استخدام نظام الحزم المجتمعي

لنعرض مثالًا باستخدام مدير وسجل الحزم لتثبيت أداة مساعدة لسطر الأوامر.

Parcel هي أداة ذكية يستخدمها المطورون لمراقبة محتويات الشيفرة لاستدعاء الاعتماديات، وتثبّتها تلقائيًا أيّ اعتماديات ترى أن شيفرتنا بحاجة إليها، ويمكنها إنشاء الشيفرة تلقائيًا.

ثبّتنا الأداة Prettier تثبيتًا عامًا لكل المشاريع في المقال السابق، ولكن سنستخدم الآن npm لتثبيت Parcel محليًا باستخدام أفضل الممارسات، وسنثبّتها بوصفها جزءًا من تطبيق تجريبي.

إعداد التطبيق بوصفه حزمة npm

أنشئ أولًا مجلدًا جديدًا لتخزين تطبيقنا التجريبي ضمنه في مكان يمكنك إيجاده بسهولة مرة أخرى، وسنسميه parcel-experiment، ولكن بالطبع يمكنك تسميته ما تشاء:

mkdir parcel-experiment
cd parcel-experiment

لنهيّئ بعد ذلك تطبيقنا كحزمة npm التي تُنشئ ملف الإعداد package.json الذي يسمح بحفظ تفاصيل الإعداد الخاصة بنا في حال أردنا إعادة إنشاء هذه البيئة لاحقًا، أو نشر الحزمة على سجل npm بالرغم من أن ذلك إلى حد ما خارج نطاق هذا المقال.

اكتب الأمر التالي، وتأكد من أنك داخل الدليل parcel-experiment:

npm init

ستُطرَح بعض الأسئلة عليك الآن، ثم سينشئ npm ملف package.json افتراضي بناءً على إجاباتك:

name: الاسم الذي يعرّف التطبيق. اضغط على زر Enter لقبول الاسم parcel-experiment الافتراضي.
version: رقم إصدار البداية الخاص بالتطبيق. اضغط على زر Enter لقبول الإصدار 1.0.0 الافتراضي.
description: وصف سريع للغرض من التطبيق. اكتب شيئًا بسيطًا مثل "حزمة npm بسيطة للتعرف على كيفية استخدام npm"، ثم اضغط على زر Enter.
entry point: يمثل ملف جافاسكربت ذي المستوى الأعلى في التطبيق. الملف index.js الافتراضي مناسب حاليًا، ثم اضغط على زر Enter.
test command وgit repository وkeywords: اضغط على زر Enter لترك هذه الخيارات فارغة حاليًا.
author: مؤلف المشروع. اكتب اسمك، ثم اضغط على زر Enter.
license: ترخيص نشر الحزمة. اضغط على زر Enter لقبول الإعداد الافتراضي حاليًا.

اضغط على زر Enter مرة أخرى لقبول هذه الإعدادات.

انتقل إلى المجلد parcel-experiment وستجد أن لديك الملف package.json. افتحه ويجب أن يبدو كما يلي:

{
  "name": "parcel-experiment",
  "version": "1.0.0",
  "description": "A simple npm package to learn about using npm",
  "main": "index.js",
  "scripts": {
    "test": "echo \"Error: no test specified\" && exit 1"
  },
  "author": "Chris Mills",
  "license": "ISC"
}

إذ يمثل ملف الإعداد الذي يحدد حزمتك.

تثبيت Parcel

شغّل الأمر التالي لتثبيت Parcel محليًا:

npm install parcel-bundler

سنكون بعد ذلك جاهزين للتطوير الحديث من طرف العميل الذي يعني استخدام أدوات البناء لتسهيل العمل على المطور. ألقِ نظرة أخرى على ملف package.json أولًا، ستلاحظ أن npm أضاف حقلًا جديدًا وهو الاعتماديات dependencies:

"dependencies": {
  "parcel-bundler": "^1.12.4"
}

إذا نقلتَ في المستقبل قاعدة شيفرتك إلى موقع آخر على جهاز آخر، فيمكنك إعادة إنشاء الإعداد نفسه عن طريق تشغيل الأمر npm install، وسينظر npm في الاعتماديات ثم يثبّتها لك. لكن أحد مساوئ npm هو أن Parcel متاح فقط ضمن التطبيق parcel-experiment، إذ لن تتمكن من تشغيله في مجلد مختلف.

إعداد التطبيق

يتوقّع Parcel أن يعمل ملف index.html وملف index.js، ولكن بخلاف ذلك ليست بنية مشروعك مُعلَنة. يمكن أن تكون الأدوات الأخرى مختلفة، ولكن تسهّل الأداة Parcel على الأقل من تجربتنا الأولية.

يجب إضافة ملف index.html إلى دليل عملنا. أنشئ الملف index.html في دليل الاختبار الخاص بك، وضع فيه المحتويات التالية:

<!DOCTYPE html>
<html lang="en-US">
  <head>
    <meta charset="utf-8">
    <title>My test page</title>
  </head>
  <body>
    <script src="./index.js"></script>
  </body>
</html>

يجب بعد ذلك إضافة ملف index.js في دليل الملف index.html نفسه. يمكن أن يكون الملف index.js فارغًا حاليًا، ولكن يجب أن يكون موجودًا لذلك أنشئه الآن.

تطبيق Parcel

سنشغّل الآن أداة Parcel المثبَّتة حديثًا. شغّل الأمر التالي في طرفيتك:

parcel index.html

يجب أن ترى شيئًا كالتالي مطبوعًا على طرفيتك:

Server running at http://localhost:1234
✨  Built in 193ms.

إذا واجهتَ مشكلةً في الطرفية التي تعرض خطأ من النوع "الأمر غير موجود command not found"، فحاول تشغيل الأمر السابق باستخدام الأداة npx مثل الأمر npx parcel index.html.

يمكننا الآن الاستفادة من نظام حزمة جافاسكربت المجتمعي الكامل. يوجد حاليًا خادم ويب محلي يعمل على العنوان http://localhost:1234، فإذا انتقلت إليه، فلن ترى أي شيء حاليًا، ولكن ستعيد Parcel بنائه وستعمل على تحديث الخادم تلقائيًا عند إجراء تعديلات على تطبيقك لتتمكن من رؤية تأثير التحديث مباشرة.

لنفترض أننا نريد عرض التواريخ النسبية التي يمكن قراءتها، مثل "منذ ساعتين 2‎ hours ago" و"قبل 4 أيام 4‎ days ago" وما إلى ذلك. يُعَد التابع formatDistanceToNow()‎ الخاص بالحزمة date-fns مفيدًا لذلك، وهناك حزم أخرى تطبّق الشي نفسه.

أضف الشيفرة التالية في ملف index.js واحفظها:

import { formatDistanceToNow } from 'date-fns'

const date = '1996-09-13 10:00:00';
document.body.textContent = formatDistanceToNow(new Date(date)) + ' ago';

ارجع إلى http://localhost:1234 وسترى كم مضى منذ بلوغ المؤلف 18 عامًا.

ما يميز الشيفرة السابقة هو أنها تستخدم الدالة formatDistanceToNow()‎ من الحزمة date-fns التي لم نثبّتها. اكتشفت الأداة Parcel أنك بحاجة الوحدة، وبحثت عنها في سجل الحزمة npmjs.com، وثبّتتها محليًا تلقائيًا. يمكنك إثبات ذلك من خلال البحث في ملف package.json مرة أخرى، وسترى تحديث حقل الاعتماديات dependencies كما يلي:

"dependencies": {
  "date-fns": "^2.12.0",
  "parcel-bundler": "^1.12.4"
}

كما أضافت Parcel الملفات المطلوبة لشخص آخر لأخذ هذا المشروع وتثبيت أي اعتماديات استخدمناها. إذا ألقيت نظرة على الدليل الذي شغّلتَ أمر parcel فيه، فستجد عددًا من الملفات الجديدة مثل:

node_modules: ملفات اعتماديات Parcel وdate-fns.
dist: دليل التوزيع distribution directory، وهو الملفات المُجمَّعة والمُصغَّرة تلقائيًا التي أنشتأها Parcel، والملفات المُخدَّمة على العنوان localhost:1234، وهي الملفات التي ستحمّلها إلى خادم الويب الخاص بك عند إطلاق الموقع عبر الإنترنت ليراه المستخدمين.

طالما أننا نعرف اسم الحزمة، فيمكننا استخدامها في شيفرتنا وستوقِف Parcel تشغيل الحزمة -أو نسخة منها- وتجلبها وتثبّتها في دليلنا المحلي ضمن node_modules.

بناء الشيفرة للإنتاج

لا تعدّ الشيفرة السابقة جاهزة للإنتاج، إذ يكون لمعظم أنظمة أدوات البناء وضع تطوير Development Mode ووضع إنتاج Production Mode. الاختلاف المهم هو أن الكثير من الميزات المفيدة التي ستستخدمها في التطوير ليست ضرورية في الموقع النهائي، لذلك ستُستبعَد للإنتاج مثل استبدال الوحدة وإعادة التحميل المباشر والشيفرة المصدرية غير المضغوطة والمُعلَّقة. هذه بعض ميزات تطوير الويب الشائعة المفيدة جدًا في مرحلة التطوير، ولكنها ليست مفيدة في مرحلة الإنتاج.

أوقِف أمر Parcel السابق باستخدام الاختصار Ctrl + C. يمكننا الآن تجهيز أساسات موقع لنشره وهميًا، إذ توفّر Parcel أمرًا إضافيًا لإنشاء ملفات مناسبة للنشر، وإنشاء حزم Bundles مع خيار البناء.

شغّل الأمر التالي:

parcel build index.html

ويجب أن ترى الناتج التالي:

✨  Built in 9.35s.

dist/my-project.fb76efcf.js.map    648.58 KB     64ms
dist/my-project.fb76efcf.js        195.74 KB    8.43s
dist/index.html                        288 B    806ms

وجهة ملفات الإنتاج هي الدليل dist.

تقليل حجم ملف التطبيق

حجم حزمة جافاسكربت my-project.fb76efcf.js هو 195K وهو حجم كبير جدًا، بالرغم من أن كل ما تفعله هو طباعة سطر نصي. هناك بالتأكيد بعض الحسابات، ولكننا لسنا بحاجة إلى 195K من شيفرة جافاسكربت لذلك.

يجدر بك التساؤل عما إذا كانت أدوات التطوير تطبّق الشيء الصحيح عن استخدامها، إذ يبلغ حجم الحزمة 200K تقريبًا في مثالنا لأنها تضمّنت مكتبة date-fns الكاملة، وليس الدالة التي نستخدمها فقط.

إذا تجنّبنا استخدام أي أدوات تطوير واستخدمنا العنصر <script src=""‎> مع إصدار مستضاف من date-fns، فسيحدث الشيء نفسه تقريبًا، وستُنزَّل المكتبة عند تحميل صفحة مثالنا في المتصفح.

يمكننا أن نطلب من البرنامج أثناء وجود الأدوات على أجهزتنا فحص استخدامنا للشيفرة وتضمين الدوال التي نستخدمها في مرحلة الإنتاج فعليً فقط، وهي عملية تُعرف باسم هز الشجرة Tree Shaking. يُعَد ذلك منطقيًا لأننا نريد تقليل حجم الملف وبالتالي تحميل تطبيقنا في أسرع وقت ممكن، وتتيح الأدوات المختلفة تطبيق تقنية هز الشجرة بطرق مختلفة.

هناك ثلاثة عروض رئيسية للأدوات التي تنشئ حزمًا من الشيفرة المصدرية هي: Webpack وRollup وParcel. سيكون هناك مزيد من الخيارات المتاحة، لكن تُعَد الأنواع التالية شائعة الاستخدام:

تقدم أداة RollUp تقنية هز الشجرة وتقسيم الشيفرة.
تتطلب أداة Webpack إعدادًا، بالرغم من أن البعض يقلل من تعقيد إعداد Webpack الخاص بالمطورين.
هناك في حالة Parcel -قبل الإصدار Parcel 2- راية خاصة مطلوبة هي ‎--experimental-scope-hoisting التي ستهز الشجرة أثناء البناء.

لنستخدم Parcel حاليًا، بما أننا ثبّتناها سابقًا. لنشغّل الأمر التالي:

parcel build index.html --experimental-scope-hoisting

سترى أن هذا الأمر يحدث فرقًا كبيرًا:

✨  Built in 7.87s.

dist/my-project.86f8a5fc.js    10.34 KB    7.17s
dist/index.html                   288 B    753ms

أصبح حجم الحزمة حوالي 10K، وهذا أفضل بكثير.

إذا أردنا إصدار هذا المشروع إلى خادم، فسنعدّل الملفات الموجودة في مجلد dist، إذ تتعامل Parcel تلقائيًا مع جميع تغييرات اسم الملف. نوصي بإلقاء نظرة على الشيفرة المصدرية في dist/index.html لتتمكن من رؤية التغييرات التي أجرتها Parcel تلقائيًا.

اقتباس

ملاحظة: لم يكن الإصدار Parcel 2 صادرًا في وقت كتابة النسخة الأجنبية من هذا المقال، ولكن ستبقى جميع هذه الأوامر تعمل عند إصداره لأن مؤلفي Parcel لديهم الحس السليم لتسمية الأداة بطريقة مختلفة. يمكنك تثبيت Parcel 1.x من خلال تثبيت parcel-bundler، لكن الإصدار parcel 2.x يسمّى parcel.

توجد الكثير من الأدوات المتاحة، وينمو نظام حزمة جافاسكربت المجتمعي بمعدل غير مسبوق، وهو أمر له إيجابيات وسلبيات. كما تُجرَى تحسينات طوال الوقت، لكن يجب معرفة قدرة الأداة قبل اختيارها.

دليل عملاء مدير الحزم

ثبّتنا في مثالنا حزمة Parcel باستخدام npm، ولكن هناك بعض البدائل كما ذكرنا سابقًا، لذلك لنلقِ نظرة عليها. سنذكر بعض مدراء الحزم وهي:

npm في npmjs.org.
pnpm في pnpm.js.org.
yarn في yarnpkg.com.

يتشابه npm وpnpm من وجهة نظر سطر الأوامر، ويهدف pnpm إلى الحصول على تكافؤ كامل مع خيارات الوسطاء التي يقدمها npm، ولكنهما يختلفان إذ يستخدم pnpm طريقة مختلفة لتنزيل الحزم وتخزينها على حاسوبك بهدف تقليل المساحة الإجمالية المطلوبة على القرص الصلب. سنستخدم npm في الأمثلة التالية، ويمكنك استخدام pnpm وسيعمل الأمر بطريقة صحيحة.

يُعتقَد أن yarn أسرع من npm من ناحية عملية التثبيت في أغلب الأحيان، وهذا مهم للمطورين بسبب وجود قدر كبير من الوقت الضائع في انتظار تثبيت الاعتماديات والنسخ إلى الحاسوب.

اقتباس

ملاحظة: مدير الحزم npm غير مطلوب لتثبيت الحزم من سجل npm، بالرغم من أنهما يشتركان في الاسم نفسه. يمكن أن يستخدم كل من pnpm وyarn تنسيق package.json نفسه الذي يستخدمه npm، ويمكنهما تثبيت أي حزمة من سجل npm وسجلات الحزم الأخرى.

لنراجع الآن الإجراءات الشائعة التي يجب تنفيذها مع مدير الحزم.

بدء مشروع جديد

npm init
yarn init

ستوجهك الأوامر السابقة وترشدك عبر سلسلة من الأسئلة لوصف مشروعك مثل الاسم والترخيص والوصف وما إلى ذلك، ثم إنشاء ملف package.json الذي يحتوي على معلومات وصفية حول مشروعك واعتمادياته.

تثبيت الاعتماديات

npm install date-fns
yarn add date-fns

رأينا أمر التثبيت install قيد التنفيذ أعلاه الذي سيؤدي إلى إضافة حزمة date-fns مباشرة إلى دليل العمل ضمن دليل فرعي يسمى node_modules مع اعتماديات date-fns.

سيثبّت الأمر السابق افتراضيًا أحدث إصدار من date-fns، ولكن يمكنك التحكم في ذلك، إذ يمكنك استخدام الأمر date-fns@1 الذي يمنحك أحدث إصدار من 1‎.x وهو 1.30.1، أو يمكنك تجربة الأمر date-fns@^2.3.0 الذي يعطي أحدث إصدار يتضمن الإصدار 2.3.0 أو بعده (2.8.1 في وقت كتابة النسخة الأجنبية من هذا المقال).

تحديث الاعتماديات

npm update
yarn upgrade

سينظر الأمر السابق في الاعتماديات المثبَّتة حاليًا ويحدّثها عند وجود تحديث متاح ضمن المجال المحدّد في الحزمة. حُدِّد المجال في إصدار الاعتمادية في ملف package.json الخاص بك مثل date-fns^2.0.1، إذ يعني المحرف ^ جميع الإصدارات الثانوية وإصدارات تصحيح الأخطاء التي تتضمن الإصدار 2.0.1 والإصدارات التي بعدها باستثناء الإصدار 3.0.0.

يُحدَّد الإصدار باستخدام نظام يسمى semver الذي يبدو معقدًا بعض الشيء في توثيقه، ولكن يمكن تبسيطه من خلال النظر فقط في المعلومات الموجزة، ويُمثّل الإصدار بالشكل MAJOR.MINOR.PATCH مثل 2.0.1، إذ يمثل الرقم 2 الإصدار الرئيسي Major Version ويمثل الرقم 1 إصدار تصحيح الأخطاء Patch Version. يمكنك تجربة قيم Semver باستخدام حاسبة semver.

يجب أن نتذكر أن الأمر npm update لن يرقّي الاعتماديات خارج المجال المحدَّد في ملف package.json، وإنما يثبت الإصدار الموجود على وجه التحديد.

تدقيق الثغرات

npm audit
yarn audit

سيؤدي الأمر السابق إلى التحقق من كامل شجرة اعتمادية مشروعك وتشغيل الإصدارات المحدَّدة التي تستخدمها لتلافي ثغرات قاعدة البيانات وإعلامك إذا كانت هناك حزم ذات ثغرات محتمَلة في مشروعك.

يُعَد مشروع Snyk نقطة انطلاق جيدة للتعرف على الثغرات، والذي يغطي كلًا من حزم جافاسكربت ولغات البرمجة الأخرى.

التحقق من الاعتمادية

npm ls date-fns
yarn why date-fns

يظهِر الأمر السابق إصدار الاعتمادية المُثبَّتة وكيفية تضمينها في مشروعك، ويُحتمَل سحب حزمة أخرى ذات مستوى أعلى في date-fns. كما يمكن أن يكون لديك إصدارات متعددة من حزمة معينة في مشروعك، ولوحظ هذا الأمر عدة مرات مع حزمة lodash أنها مفيدة جدًا لضمان عمل كافة الشيفرة البرمجية.

يمكن أن ترغب في التحقق بالضبط من الإصدار المثبت، بالرغم من أن مدير الحزم سيبذل قصارى جهده لإزالة تكرار الحزم.

إنشاء أوامرك الخاصة

يدعم مدير الحزم إنشاء أوامرك الخاصة وتنفيذها من سطر الأوامر، إذ يمكننا استخدام الأمر التالي مثلًا:

npm run dev
# ‫ أو yarn run dev

سيؤدي الأمر السابق إلى تشغيل سكربت مخصص لبدء مشروعنا في وضع التطوير، ويمكننا تضمينه بانتظام في جميع المشاريع إذ يميل إعداد التطوير المحلي إلى العمل بطريقة مختلفة عن كيفية تشغيله في عملية الإنتاج.

إذا حاولت تشغيل هذا السكربت في مشروع اختبار Parcel الخاص بك، فيُحتمَل أن يدّعي أن السكربت dev مفقود، لأن npm وyarn يبحثان عن خاصية تسمى dev ضمن الخاصية scripts لملف package.json الخاص بك.

يمكن أن تشغّل Parcel خادم تطوير باستخدام الأمر parcel serve filename.html، لأننا سنرغب في استخدامه كثيرًا أثناء عملية التطوير، لذلك لننشئ أمر مخصَّصًا مختصرًا هو "dev" في ملف package.json.

يجب أن يكون لديك ملف package.json ضمن الدليل parcel-experiment. افتحه ويجب أن تبدو الخاصية scripts كما يلي:

"scripts": {
  "test": "echo \"Error: no test specified\" && exit 1",
},

حدّثها لتبدو كما يلي، ثم احفظ الملف:

"scripts": {
  "test": "echo \"Error: no test specified\" && exit 1",
  "dev": "parcel serve index.html"
},

أضفنا الأمر dev المخصص بوصفه سكربت npm.

حاول الآن تشغيل الأمر التالي في طرفيتك، وتأكد من أنك ضمن الدليل parcel-experiment:

npm run dev

يجب أن يبدأ الأمر السابق Parcel ويقدم ملف index.html الخاص بك على خادم التطوير المحلي كما رأينا سابقًا:

Server running at http://localhost:1234
✨  Built in 5.48s.

كما تُعَد أوامر npm وyarn ذكية من لأنها ستبحث عن أدوات سطر الأوامر المثبَّتة محليًا للمشروع قبل محاولة العثور عليها من خلال الطرق التقليدية، ويخزّن حاسوبك عادةً البرامج ويسمح بإيجادها. يمكنك معرفة المزيد حول تعقيدات الأمر run، بالرغم من أن سكربتاتك ستعمل بصورة جيدة في معظم الحالات.

يمكنك إضافة جميع الأنواع إلى الخاصية scripts التي تساعدك على أداء عملك.

إلى هنا تنتهي جولتنا في التعرف على مدير الحزم، وخطوتنا التالية هي بناء نموذج لسلسلة أدوات، ووضع كل ما تعلمناه حتى الآن موضع التنفيذ.

هذا المقال جزء من سلسلة مقالات بعنوان تعلم تطوير الويب والتي تشرح كامل عملية تطوير الويب من واجهات أمامية وخلفية بالكامل.

ترجمة -وبتصرُّف- للمقال Package management basics.