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

الشكل الأفضل

حُلَّ التبعيّات حيث تملك الموارد، وأرسل النتيجة. عندها لا يشغّل الخادم Composer إطلاقًا.

# on your machine or in CI
composer install --no-dev --optimize-autoloader --classmap-authoritative
rsync -az --delete vendor/ user@server:/var/www/site/vendor/
  • --no-dev — أطر الاختبار وأدوات التنقيح لا مكان لها في الإنتاج.
  • --optimize-autoloader — خريطة أصناف بدل الاستعلام عن نظام الملفّات، وتسريعٌ يمكن قياسه.
  • --classmap-authoritative — لا نداءات stat احتياطية إطلاقًا. استعمله فقط حين لا يولّد شيءٌ أصنافًا أثناء التشغيل.

وإن اضطررت إلى تشغيله على الخادم

php -d memory_limit=-1 /usr/local/bin/composer install --no-dev --optimize-autoloader

حدُّ الذاكرة هو العائق المعتاد. ورفعه لذلك الأمر وحده يجنّبك رفعه للموقع كلّه.

أدخِل ملفّ القفل في المستودع، ولا تُدخل مجلّد vendor أبدًا

ملفّ composer.lock مكانه في git — فهو ما يجعل تثبيتَين متطابقَين. أمّا مجلّد vendor فلا: يجعل المستودع ضخمًا والدمج مستحيلًا.

وانشر بلا نافذة مكسورة

نسخ الملفّات إلى مجلّد حيّ يعني أن بعض الطلبات ترى نصف الشفرة الجديدة. ابنِ في مجلّد جديد وبدّل رابطًا رمزيًّا، فيصير التغيير ذرّيًّا.

ln -sfn /var/www/releases/2026-09-05 /var/www/current
sudo systemctl reload php8.3-fpm       # clear the opcache of the old paths
وأعِد تحميل PHP-FPM بعد كل نشر وإلّا ظلّ opcache يقدّم الشفرة السابقة من الذاكرة — انظر ماذا يخبّئ opcache.