إزالة حزمة في Laravel عبر Composer: دليل خطوة بخطوة

مقدمة: لماذا "الزوائد" في المشروع ضارة، وكيف يساعدك Composer في التخلص منها

هل لاحظت يومًا كيف يتحول مشروع Laravel مع الوقت إلى مستودع ضخم من الحزم غير الضرورية؟ قد تكون قمت بتثبيت حزمة لنموذج أولي، وأخرى لتجربة، وثالثة "فقط في حالة". ثم يستمر المشروع في النمو والتطور، بينما تظل هذه الحزم عبئًا ثقيلًا، مما يضخم مجلد vendor ويبطئ عملية composer install.

عاجلاً أم آجلاً، يسأل كل مطور نفسه: "كيف يمكنني إزالة حزمة من Laravel باستخدام PHP Composer؟". وهذه ليست مجرد عملية تقنية - بل هي فن ترتيب الأولويات. اليوم سنشرح هذه العملية من الألف إلى الياء: ليس فقط الأوامر، بل دورة التنظيف الكاملة مع أمثلة ونصائح وحلول للمشاكل الشائعة.

هل أنت مستعد لتحويل مشروعك من "مكب للتبعيات" إلى نظام منظم؟ هيا بنا!

ما يجب معرفته قبل إزالة الحزمة

قبل تشغيل composer remove، دعنا نفهم كيف يدير Composer التبعيات بشكل عام. في Laravel (وأي مشروع PHP)، يعمل Composer من خلال ملفين رئيسيين:

\n
• composer.json - قائمة بجميع الحزم المطلوبة وإصداراتها.
\n
• composer.lock - لقطة دقيقة للإصدارات المثبتة، لضمان عمل المشروع بنفس الطريقة على جميع الأجهزة.
\n

عند إزالة حزمة، يقوم Composer بتحديث كلا الملفين: يزيل الإدخال من composer.json ويعيد حساب composer.lock بدون التبعية المحذوفة. لكن هناك نقطة مهمة: إذا كانت الحزمة مستخدمة من قبل حزم أخرى، سيرفض Composer إزالتها. أداة ذكية، بلا شك.

الأمر الأساسي: composer remove

أبسط وأصح طريقة لإزالة حزمة هي استخدام الأمر المدمج composer remove. الصيغة بسيطة للغاية:

composer remove vendor/package-name

على سبيل المثال، إذا كنت تريد إزالة الحزمة الشهيرة للتصحيح barryvdh/laravel-debugbar، سيكون الأمر كالتالي:

composer remove barryvdh/laravel-debugbar

بعد التنفيذ، سترى مخرجات مشابهة لهذه:

Package "barryvdh/laravel-debugbar" removed from require\nLoading composer repositories with package information\nUpdating dependencies (including require-dev)\nNothing to install or update\nGenerating optimized autoload files\n

هذا كل شيء! اختفت الحزمة من vendor و composer.json و composer.lock. لكن هذه مجرد البداية. السحر الحقيقي يحدث عندما تبدأ بتنظيف المشروع من "الآثار الجانبية".

إزالة تبعيات التطوير (dev-dependencies)

إذا كانت الحزمة مثبتة فقط لأغراض التطوير (مثل phpunit/phpunit)، فهي عادةً ما تكون مكتوبة في قسم require-dev. Composer يفهم تلقائيًا من أين يحذف، ولكن للتأكيد يمكنك استخدام العلم --dev:

composer remove --dev phpunit/phpunit

هذا يضمن أن الأمر سيتم تطبيقه على تبعيات التطوير فقط. على الرغم من أن Composer في الواقع يتعامل معها بشكل ممتاز حتى بدون العلم.

الإزالة اليدوية: عندما تعجز الأتمتة

هناك حالات يرفض فيها composer remove العمل. على سبيل المثال، إذا كانت الحزمة تابعية لحزمة أخرى لم تقم بإزالتها. أو إذا قمت بحذف الإدخال من composer.json يدويًا عن طريق الخطأ، وبقيت الحزمة في vendor.

في مثل هذه الحالات، يجب التصرف بحزم. إليك خوارزمية الإزالة اليدوية:

\n
1. احذف إدخال الحزمة من قسم require أو require-dev في ملف composer.json.
\n
2. احذف مجلد الحزمة من vendor/vendor/package-name (يمكنك ببساطة مسح مجلد vendor بالكامل - لكن هذا إجراء جذري).
\n
3. شغّل composer update
\n