اگر با PHP کار کرده باشید، احتمالاً با پروژه‌هایی مواجه شده‌اید که از کتابخانه‌ها و پکیج‌های مختلف استفاده می‌کنند. برای مثال ممکن است یک پروژه به یک کتابخانه برای کار با API، یک ابزار برای پردازش فایل، یک سیستم Logging یا چندین Dependency دیگر نیاز داشته باشد.
مدیریت دستی این Dependencyها در پروژه‌های بزرگ بسیار دشوار است.
اینجاست که Composer وارد می‌شود.
Composer ابزار استاندارد مدیریت Dependency در اکوسیستم PHP است که به برنامه‌نویس اجازه می‌دهد کتابخانه‌ها و پکیج‌های موردنیاز پروژه را تعریف، نصب، به‌روزرسانی و مدیریت کند.
Composer علاوه بر مدیریت Dependency، قابلیت بسیار مهم دیگری به نام Autoloading نیز در اختیار پروژه قرار می‌دهد.
در این مقاله بررسی می‌کنیم:
- Composer چیست؟
- چرا به Composer نیاز داریم؟
- Composer در PHP چه کاربردی دارد؟
composer.jsonچیست؟composer.lockچیست؟- Packagist چیست؟
- تفاوت
installوupdateچیست؟ requireوrequire-devچه تفاوتی دارند؟- Composer چگونه Autoload را مدیریت می‌کند؟
- Composer چه ارتباطی با Namespace و PSR-4 دارد؟
- و چطور باید از Composer در پروژه‌های PHP استفاده کنیم؟
# Composer چیست؟
Composer یک Dependency Manager برای PHP است.
به زبان ساده، Composer ابزاری است که به شما کمک می‌کند کتابخانه‌ها و پکیج‌های موردنیاز پروژه PHP خود را مدیریت کنید.
فرض کنید پروژه شما به یک Package با نام فرضی:
vendor/package
نیاز دارد.
به جای اینکه فایل‌های آن Package را به صورت دستی دانلود کنید، Composer می‌تواند Dependency را دریافت و نصب کند.
برای نصب یک Package معمولاً از دستوری مانند زیر استفاده می‌شود:
composer require vendor/package
Composer Dependency موردنظر و Dependencyهای موردنیاز آن را بررسی کرده و آنها را در پروژه نصب می‌کند.
# چرا به Composer نیاز داریم؟
فرض کنید یک پروژه PHP بزرگ دارید و از ۱۰ کتابخانه مختلف استفاده می‌کنید.
بدون یک Dependency Manager باید:
- کتابخانه‌ها را جداگانه دانلود کنید.
- نسخه مناسب آنها را پیدا کنید.
- Dependencyهای هر کتابخانه را بررسی کنید.
- فایل‌های موردنیاز را در پروژه قرار دهید.
- هنگام آپدیت کتابخانه‌ها، نسخه‌ها را مدیریت کنید.
- مطمئن شوید Packageهای مختلف با یکدیگر سازگار هستند.
این فرآیند بسیار زمان‌بر و مستعد خطاست.
Composer این کارها را تا حد زیادی خودکار می‌کند.
# Composer چه کاری انجام می‌دهد؟
مهم‌ترین قابلیت‌های Composer عبارت‌اند از:
- نصب Packageهای PHP
- مدیریت Dependencyها
- مدیریت نسخه Packageها
- بررسی سازگاری Dependencyها
- نصب Dependencyهای غیرمستقیم
- به‌روزرسانی Packageها
- ایجاد Autoloader
- مدیریت Dependencyهای Development
- اجرای Scriptهای پروژه
- استفاده از Packageهای موجود در اکوسیستم PHP
# Package در PHP چیست؟
قبل از اینکه Composer را بهتر درک کنیم، باید بدانیم Package چیست.
Package مجموعه‌ای از کدهای قابل استفاده مجدد است که می‌تواند قابلیت مشخصی را به پروژه اضافه کند.
برای مثال یک Package می‌تواند برای:
- ارسال ایمیل
- کار با API
- پردازش تصویر
- تولید PDF
- Logging
- احراز هویت
- اتصال به سرویس‌های خارجی
- کار با Database
- تست نرم‌افزار
استفاده شود.
به جای اینکه همه این قابلیت‌ها را از صفر بنویسیم، می‌توانیم از Packageهای آماده استفاده کنیم.
# Dependency چیست؟
Dependency به کدی گفته می‌شود که پروژه شما برای انجام بخشی از عملکرد خود به آن نیاز دارد.
مثلاً اگر پروژه شما از یک کتابخانه PDF استفاده کند، آن کتابخانه یک Dependency برای پروژه شما محسوب می‌شود.
ممکن است خود آن Package نیز به Package دیگری نیاز داشته باشد.
در نتیجه ساختار Dependency می‌تواند به شکل زیر باشد:
Project
│
├── Package A
│ ├── Package C
│ └── Package D
│
└── Package B
└── Package E
Composer این Dependencyها را مدیریت می‌کند.
# Composer چگونه Dependencyها را مدیریت می‌کند؟
فرض کنید در پروژه خود دستور زیر را اجرا می‌کنید:
composer require monolog/monolog
Composer بررسی می‌کند:
- Package موردنظر چیست؟
- چه نسخه‌هایی از آن وجود دارد؟
- پروژه شما با کدام نسخه سازگار است؟
- Package به چه Dependencyهایی نیاز دارد؟
- Dependencyهای آن چه نسخه‌هایی لازم دارند؟
سپس مجموعه مناسب Dependencyها را نصب می‌کند.
# Packagist چیست؟
Packagist یکی از مهم‌ترین منابع Packageهای PHP است و مخزن اصلی Composer برای Packageهای عمومی PHP محسوب می‌شود.
وقتی دستوری مانند:
composer require monolog/monolog
اجرا می‌کنید، Composer اطلاعات Package را از Repository مربوطه دریافت می‌کند.
نام Package معمولاً به شکل زیر نوشته می‌شود:
vendor/package
مثلاً:
monolog/monolog
# ساختار نام Package در Composer
Packageها معمولاً دارای دو بخش هستند:
vendor/package
مثلاً:
guzzlehttp/guzzle
در اینجا:
guzzlehttp
Vendor و:
guzzle
نام Package است.
این ساختار باعث می‌شود Packageها نام مشخص و قابل شناسایی داشته باشند.
# composer.json چیست؟
یکی از مهم‌ترین فایل‌های Composer:
composer.json
است.
این فایل اطلاعات مربوط به پروژه و Dependencyهای آن را نگهداری می‌کند.
یک نمونه ساده:
{
"require": {
"monolog/monolog": "^3.0"
}
}
در این مثال پروژه به Package زیر نیاز دارد:
monolog/monolog
با یک Constraint نسخه مشخص.
# ساخت composer.json
می‌توانیم Composer را در یک پروژه PHP با دستور:
composer init
راه‌اندازی کنیم.
Composer از شما اطلاعات مختلفی درباره پروژه می‌پرسد و در نهایت یک composer.json ایجاد می‌کند.
البته در بسیاری از پروژه‌ها این فایل از قبل وجود دارد.
# ساختار composer.json
یک composer.json می‌تواند بخش‌های مختلفی داشته باشد.
مثلاً:
{
"name": "example/project",
"description": "Example PHP project",
"require": {
"monolog/monolog": "^3.0"
},
"require-dev": {
"phpunit/phpunit": "^11.0"
}
}
مهم‌ترین بخش‌هایی که در پروژه‌های معمول مشاهده می‌کنید:
name
description
require
require-dev
autoload
autoload-dev
scripts
config
هستند.
# require در Composer چیست؟
بخش:
{
"require": {}
}
برای Dependencyهایی استفاده می‌شود که پروژه در اجرای اصلی خود به آنها نیاز دارد.
مثلاً:
{
"require": {
"monolog/monolog": "^3.0"
}
}
یعنی Monolog یک Dependency اصلی پروژه است.
# require-dev چیست؟
Dependencyهایی که فقط در محیط Development یا Testing استفاده می‌شوند معمولاً در:
{
"require-dev": {}
}
قرار می‌گیرند.
مثلاً:
{
"require-dev": {
"phpunit/phpunit": "^11.0"
}
}
اگر پروژه را برای Production آماده می‌کنید، معمولاً می‌توانید Dependencyهای Development را نصب نکنید.
مثلاً:
composer install --no-dev
# تفاوت require و require-dev
به طور خلاصه:
| بخش | کاربرد |
|---|---|
require | Dependencyهای موردنیاز Runtime |
require-dev | ابزارهای Development و Testing |
مثلاً:
Laravel
Redis Client
HTTP Client
ممکن است در require باشند.
اما:
PHPUnit
PHPStan
Pest
معمولاً در require-dev قرار می‌گیرند.
# نسخه Package در Composer
Composer امکان تعریف Constraint برای نسخه Package را فراهم می‌کند.
مثلاً:
{
"require": {
"vendor/package": "^2.0"
}
}
این Constraint مشخص می‌کند چه نسخه‌هایی می‌توانند مورد قبول Composer باشند.
یکی از قابلیت‌های مهم Composer همین مدیریت نسخه Dependencyهاست.
# علامت ^ در Composer چیست؟
مثلاً:
^2.0
یک Version Constraint است که به Composer اجازه می‌دهد در محدوده سازگار مشخصی نسخه Package را انتخاب کند.
در Semantic Versioning، مفهوم دقیق Constraintها به ساختار نسخه و قوانین Composer بستگی دارد.
به همین دلیل بهتر است هنگام تعریف Dependency، تفاوت بین:
^
~
>=
>
<
=
و ترکیب Constraintها را به خوبی بشناسید.
# composer.lock چیست؟
در کنار:
composer.json
ممکن است فایل مهم دیگری داشته باشیم:
composer.lock
این فایل نسخه دقیق Dependencyهایی را که Composer برای پروژه انتخاب کرده، ثبت می‌کند.
این موضوع برای ایجاد محیط‌های یکسان در تیم و Deployment بسیار مهم است.
# چرا composer.lock مهم است؟
فرض کنید شما امروز Dependencyهای پروژه را نصب کرده‌اید.
Composer بر اساس Constraintهای composer.json نسخه‌هایی را انتخاب می‌کند و آنها را در composer.lock ثبت می‌کند.
حالا اگر پروژه را روی Server دیگری نصب کنید:
composer install
Composer می‌تواند از نسخه‌های ثبت‌شده در Lock File استفاده کند.
در نتیجه احتمال تفاوت نسخه Dependencyها بین محیط Development و Production کاهش پیدا می‌کند.
# تفاوت composer.json و composer.lock
به زبان ساده:
composer.json
می‌گوید:
> پروژه من به چه Dependencyهایی و با چه Constraintهایی نیاز دارد؟
composer.lock
می‌گوید:
> در حال حاضر دقیقاً چه نسخه‌هایی برای این Dependencyها انتخاب و Lock شده‌اند؟
این تفاوت یکی از مهم‌ترین مفاهیم Composer است.
# composer install چیست؟
دستور:
composer install
برای نصب Dependencyهای پروژه استفاده می‌شود.
اگر composer.lock وجود داشته باشد، Composer از نسخه‌های ثبت‌شده در آن استفاده می‌کند.
این دستور معمولاً در فرآیند Deployment بسیار مهم است.
مثلاً:
composer install --no-dev --optimize-autoloader
می‌تواند برای نصب Dependencyهای Production استفاده شود.
# composer update چیست؟
دستور:
composer update
برای به‌روزرسانی Dependencyها بر اساس Constraintهای موجود در composer.json استفاده می‌شود.
این دستور می‌تواند composer.lock را نیز تغییر دهد.
به همین دلیل نباید بدون دلیل روی Production از:
composer update
استفاده کرد.
معمولاً بهتر است Dependencyها را در محیط Development به‌روزرسانی و Lock File جدید را همراه پروژه Deploy کنیم.
# تفاوت composer install و composer update
| دستور | کاربرد |
|---|---|
composer install | نصب نسخه‌های مشخص‌شده در Lock File |
composer update | پیدا کردن نسخه‌های جدید مطابق Constraintها و به‌روزرسانی Lock File |
این تفاوت در پروژه‌های تیمی و Production بسیار مهم است.
# دستور composer require
برای اضافه کردن یک Package جدید می‌توان از:
composer require vendor/package
استفاده کرد.
مثلاً:
composer require monolog/monolog
Composer:
- Package را پیدا می‌کند.
- Dependencyهای آن را بررسی می‌کند.
- آن را نصب می‌کند.
composer.jsonرا به‌روزرسانی می‌کند.composer.lockرا به‌روزرسانی می‌کند.- Autoload را نیز به‌روزرسانی می‌کند.
# حذف Package با Composer
برای حذف Dependency:
composer remove vendor/package
استفاده می‌شود.
Composer Package را از Dependencyهای پروژه حذف می‌کند و فایل‌های مربوط به Dependency Management را نیز به‌روزرسانی می‌کند.
# پوشه vendor چیست؟
بعد از اجرای Composer معمولاً پوشه‌ای به نام:
vendor/
ایجاد می‌شود.
این پوشه محل قرارگیری Dependencyهای نصب‌شده پروژه است.
مثلاً:
project/
├── app/
├── public/
├── vendor/
├── composer.json
└── composer.lock
# آیا باید پوشه vendor را داخل Git قرار دهیم؟
در اکثر پروژه‌های PHP که از Composer استفاده می‌کنند، معمولاً vendor/ را در Git Commit نمی‌کنند.
به جای آن:
composer.json
composer.lock
در Repository قرار می‌گیرند.
سپس در Server یا محیط جدید اجرا می‌شود:
composer install
و پوشه vendor دوباره ساخته می‌شود.
البته سیاست دقیق ممکن است بر اساس نوع پروژه و Deployment متفاوت باشد.
# Composer Autoload چیست؟
یکی از مهم‌ترین قابلیت‌های Composer، ایجاد Autoloader است.
بعد از نصب Dependencyها، معمولاً فایلی مانند:
vendor/autoload.php
وجود دارد.
در Application می‌توانیم آن را Load کنیم:
require __DIR__ . '/vendor/autoload.php';
بعد از آن Composer می‌تواند کلاس‌های تعریف‌شده در Autoload Configuration را به صورت خودکار Load کند.
# چرا Autoload مهم است؟
بدون Autoload ممکن است مجبور شویم برای هر کلاس:
require 'User.php';
require 'Product.php';
require 'Order.php';
بنویسیم.
در پروژه‌های بزرگ این روش بسیار نامناسب است.
Composer Autoload این فرآیند را خودکار می‌کند.
# Composer و Namespace
Composer ارتباط بسیار مهمی با Namespace دارد.
مثلاً فرض کنید:
App\Models\User
کلاس ما باشد.
در composer.json می‌توانیم Mapping زیر را داشته باشیم:
{
"autoload": {
"psr-4": {
"App\\": "app/"
}
}
}
در این حالت Namespace:
App\
به Directory:
app/
Mapping می‌شود.
# PSR-4 چیست؟
PSR-4 استانداردی برای Autoloading کلاس‌ها در PHP است.
فرض کنید:
App\Models\User
داریم.
و Mapping:
App\ -> app/
تعریف شده است.
Composer می‌تواند بر اساس این Mapping کلاس را در:
app/Models/User.php
پیدا کند.
این قابلیت باعث شده ساختار Namespace و فایل‌ها در پروژه‌های مدرن PHP بسیار منظم‌تر شود.
# composer dump-autoload چیست؟
گاهی اوقات تنظیمات Autoload را تغییر می‌دهیم و لازم است Autoloader دوباره تولید شود.
برای این کار:
composer dump-autoload
را اجرا می‌کنیم.
مثلاً اگر در composer.json چنین بخشی اضافه کرده باشیم:
{
"autoload": {
"psr-4": {
"App\\": "app/"
}
}
}
می‌توانیم اجرا کنیم:
composer dump-autoload
تا Autoload اطلاعات جدید را در نظر بگیرد.
# Autoload با Composer چگونه کار می‌کند؟
به شکل ساده:
composer.json
↓
Autoload Configuration
↓
composer dump-autoload
↓
vendor/autoload.php
↓
Application
↓
Class Loading
البته در پشت صحنه Composer چندین فایل و Mapping مختلف تولید می‌کند.
# Composer و Git
در پروژه‌های تیمی معمولاً این فایل‌ها مهم هستند:
composer.json
composer.lock
بهتر است تغییرات آنها تحت Version Control قرار بگیرد.
مثلاً:
git add composer.json composer.lock
git commit -m "Update PHP dependencies"
اما معمولاً:
vendor/
در .gitignore قرار داده می‌شود.
# Composer در پروژه Laravel
اگر با Laravel کار کرده باشید، Composer برای شما کاملاً ضروری است.
Laravel خودش مجموعه‌ای از Dependencyها را در composer.json تعریف می‌کند.
مثلاً:
{
"require": {
"laravel/framework": "...",
"laravel/sanctum": "..."
}
}
وقتی یک پروژه Laravel را Clone می‌کنید، معمولاً باید Dependencyهای آن را نصب کنید:
composer install
سپس Application می‌تواند از Packageهای موردنیاز استفاده کند.
# اضافه کردن Package به Laravel
فرض کنید بخواهیم یک Package به پروژه Laravel اضافه کنیم.
به جای دانلود دستی فایل‌ها:
composer require vendor/package
را اجرا می‌کنیم.
Composer Package را نصب و Dependencyهای آن را مدیریت می‌کند.
بسته به Package ممکن است مراحل دیگری مانند Publish Configuration، Migration یا تنظیم Service Provider نیز لازم باشد.
# Composer در پروژه‌های API
Composer فقط مخصوص Laravel نیست.
اگر یک REST API با PHP خام یا Framework دیگری بنویسید نیز می‌توانید از Composer استفاده کنید.
مثلاً:
PHP API
├── HTTP Client
├── Logger
├── Database Library
└── Testing Framework
تمام این Dependencyها می‌توانند توسط Composer مدیریت شوند.
# Composer و نسخه PHP
Dependencyها ممکن است به نسخه خاصی از PHP نیاز داشته باشند.
مثلاً یک Package ممکن است اعلام کند که به نسخه‌ای از PHP با حداقل نسخه مشخص نیاز دارد.
Composer می‌تواند این محدودیت‌ها را در هنگام Dependency Resolution بررسی کند.
بنابراین نسخه PHP محیط Development و Production باید با نیازمندی‌های پروژه سازگار باشد.
# بررسی Dependencyهای پروژه
Composer ابزارهای مختلفی برای بررسی Dependencyها دارد.
یکی از دستورات کاربردی:
composer show
است.
این دستور اطلاعات Packageهای نصب‌شده را نمایش می‌دهد.
برای بررسی Dependencyهای یک Package نیز می‌توان از دستورات مرتبط Composer استفاده کرد.
# بررسی مشکلات Dependency
یکی از دستورات مهم:
composer why
است.
مثلاً می‌توان بررسی کرد یک Package چرا در پروژه نصب شده است.
همچنین:
composer why-not
می‌تواند برای بررسی اینکه چرا یک نسخه خاص قابل نصب نیست مفید باشد.
این دستورات هنگام حل Conflictهای Composer بسیار کاربردی هستند.
# Composer و Dependency Conflict
یکی از مشکلات رایج در پروژه‌های PHP، Conflict بین نسخه Packageها است.
مثلاً:
Package A
requires Library X ^2.0
Package B
requires Library X ^3.0
ممکن است Composer نتواند مجموعه‌ای از نسخه‌ها را پیدا کند که هر دو شرط را برآورده کنند.
در چنین شرایطی باید Constraintهای Dependencyها و نسخه‌های قابل نصب بررسی شوند.
# چرا Composer Update گاهی خطا می‌دهد؟
ممکن است composer update به دلیل مواردی مانند:
- ناسازگاری نسخه PHP
- Conflict بین Packageها
- حذف شدن یک نسخه
- Constraintهای ناسازگار
- Dependencyهای قدیمی
- محدودیت‌های Platform
با خطا مواجه شود.
یکی از نکات مهم این است که نباید صرفاً با حذف composer.lock یا تغییر تصادفی Versionها مشکل را حل کرد.
ابتدا باید علت Conflict مشخص شود.
# Composer و Production
در Production معمولاً هدف این است که دقیقاً Dependencyهایی نصب شوند که قبلاً تست شده‌اند.
به همین دلیل وجود:
composer.lock
اهمیت زیادی دارد.
یک فرآیند معمول Deployment می‌تواند شامل:
git pull
composer install --no-dev --optimize-autoloader
باشد.
البته دستورات دقیق Deployment باید بر اساس معماری پروژه و Server تنظیم شوند.
# Composer در پروژه‌های بزرگ
در پروژه‌های Enterprise ممکن است ده‌ها یا حتی صدها Dependency وجود داشته باشد.
Composer در چنین پروژه‌هایی کمک می‌کند:
Application
↓
composer.json
↓
Dependency Resolution
↓
composer.lock
↓
vendor/
↓
Autoload
به شکل منظم مدیریت شود.
# آیا Composer فقط Package نصب می‌کند؟
خیر.
Composer علاوه بر نصب Dependency می‌تواند برای موارد مختلفی استفاده شود:
- Autoloading
- اجرای Script
- مدیریت نسخه Dependency
- تعریف Repository
- کنترل Platform Requirements
- مدیریت Dependencyهای Development
- اجرای ابزارهای پروژه
بنابراین Composer صرفاً یک ابزار دانلود Package نیست.
# تفاوت Composer با npm
اگر با JavaScript کار کرده باشید احتمالاً با npm آشنا هستید.
از نظر مفهوم کلی می‌توان مقایسه کرد:
| PHP | JavaScript |
|---|---|
| Composer | npm |
| Packagist | npm Registry |
| composer.json | package.json |
| vendor/ | node_modules/ |
| composer.lock | package-lock.json |
البته این ابزارها دقیقاً یکسان نیستند و هرکدام رفتار و اکوسیستم مخصوص خود را دارند.
# تفاوت Composer با Git
Composer و Git دو ابزار کاملاً متفاوت هستند.
Git
برای Version Control و مدیریت تاریخچه کد استفاده می‌شود.
Composer
برای Dependency Management و Autoloading در پروژه PHP استفاده می‌شود.
این دو ابزار معمولاً در کنار یکدیگر استفاده می‌شوند.
# بهترین روش استفاده از Composer
برای پروژه‌های حرفه‌ای PHP چند نکته را رعایت کنید:
۱. composer.json را مدیریت کنید
Dependencyهای پروژه باید شفاف و قابل بررسی باشند.
۲. composer.lock را جدی بگیرید
به‌خصوص برای Applicationهایی که Deployment قابل تکرار نیاز دارند.
۳. vendor را معمولاً Commit نکنید
Dependencyها را در محیط مقصد با Composer نصب کنید.
۴. در Production از install استفاده کنید
در اغلب فرآیندهای Deployment، استفاده از:
composer install
به جای:
composer update
انتخاب مناسب‌تری است.
۵. Dependencyهای Development را جدا کنید
ابزارهای Testing و Development را در:
require-dev
قرار دهید.
۶. Packageهای بدون نگهداری را بررسی کنید
قبل از اضافه کردن یک Dependency، وضعیت نگهداری، سازگاری و کیفیت آن را بررسی کنید.
۷. Dependencyها را بی‌دلیل به‌روزرسانی نکنید
هر Update می‌تواند تغییرات یا ناسازگاری‌هایی ایجاد کند.
# ساختار پیشنهادی یک پروژه PHP با Composer
یک پروژه ساده می‌تواند ساختار زیر را داشته باشد:
my-project/
│
├── src/
│ ├── Models/
│ ├── Services/
│ └── Repositories/
│
├── tests/
│
├── public/
│
├── vendor/
│
├── composer.json
├── composer.lock
└── .gitignore
و در composer.json:
{
"autoload": {
"psr-4": {
"App\\": "src/"
}
},
"require": {
"monolog/monolog": "^3.0"
},
"require-dev": {
"phpunit/phpunit": "^11.0"
}
}
بعد:
composer install
و:
composer dump-autoload
# Composer و معماری حرفه‌ای PHP
Composer یکی از پایه‌های اکوسیستم مدرن PHP است.
وقتی مفاهیمی مانند:
Namespace
PSR-4
Autoload
Dependency Injection
SOLID
Design Patterns
را در کنار Composer یاد می‌گیرید، می‌توانید Applicationهایی با ساختار بسیار حرفه‌ای‌تر ایجاد کنید.
به همین دلیل یادگیری Composer صرفاً برای نصب Package نیست؛ بلکه بخشی از مسیر تبدیل شدن به یک PHP Developer حرفه‌ای است.
# جمع‌بندی
Composer چیست؟
Composer یک Dependency Manager قدرتمند برای PHP است که برای مدیریت کتابخانه‌ها و Packageهای پروژه استفاده می‌شود.
با Composer می‌توانیم:
- Package نصب کنیم.
- Package حذف کنیم.
- Dependencyها را مدیریت کنیم.
- نسخه Packageها را کنترل کنیم.
- Dependencyهای Development را جدا کنیم.
- Autoload ایجاد کنیم.
- Packageها را به‌روزرسانی کنیم.
- Dependency Conflictها را بررسی کنیم.
- پروژه را برای Deployment آماده کنیم.
مهم‌ترین فایل‌ها و مفاهیمی که باید بشناسید عبارت‌اند از:
composer.json
composer.lock
vendor/
vendor/autoload.php
Packagist
require
require-dev
install
update
require
remove
dump-autoload
PSR-4
اگر در حال یادگیری PHP حرفه‌ای هستید، بعد از شناخت Composer باید وارد مرحله عملی شوید و نحوه نصب Package، تعریف Dependency، مدیریت Version، کار با composer.json و ساخت Autoload را تمرین کنید.
در مقاله بعدی، آموزش Composer را به صورت عملی بررسی می‌کنیم و دستورات مهم Composer را مرحله‌به‌مرحله اجرا خواهیم کرد.
# سوالات متداول Composer
Composer چیست؟
Composer ابزار مدیریت Dependency در PHP است که برای نصب، حذف، به‌روزرسانی و مدیریت Packageهای PHP و همچنین Autoloading استفاده می‌شود.
آیا Composer برای PHP ضروری است؟
برای پروژه‌های کوچک PHP ممکن است بدون Composer نیز بتوان کار کرد؛ اما در پروژه‌های مدرن و حرفه‌ای PHP، Composer یکی از ابزارهای اصلی اکوسیستم PHP محسوب می‌شود.
composer.json چیست؟
composer.json فایل اصلی تعریف مشخصات پروژه و Dependencyهای آن است.
composer.lock چیست؟
composer.lock نسخه دقیق Dependencyهای انتخاب‌شده برای پروژه را ثبت می‌کند تا نصب Dependencyها در محیط‌های مختلف قابل تکرارتر باشد.
Packagist چیست؟
Packagist مخزن اصلی و عمومی Packageهای PHP برای Composer است و تعداد زیادی از کتابخانه‌های PHP در آن منتشر می‌شوند.
تفاوت composer install و composer update چیست؟
composer install برای نصب Dependencyهای پروژه، معمولاً بر اساس composer.lock، استفاده می‌شود؛ در حالی که composer update Dependencyها را بر اساس Constraintهای composer.json مجدداً حل کرده و در صورت نیاز نسخه‌های جدید را انتخاب می‌کند.
دستور composer require چیست؟
برای اضافه کردن یک Package جدید به پروژه استفاده می‌شود:
composer require vendor/package
پوشه vendor در Composer چیست؟
پوشه vendor محل قرارگیری Dependencyهای نصب‌شده پروژه و فایل‌های Autoload مربوط به Composer است.
آیا vendor باید در Git قرار بگیرد؟
در اکثر پروژه‌های PHP معمولاً vendor/ در Git قرار نمی‌گیرد و Dependencyها با استفاده از composer install در محیط مقصد نصب می‌شوند.
Composer و Namespace چه ارتباطی دارند؟
Composer می‌تواند با استفاده از PSR-4 بین Namespace و مسیر فایل‌ها Mapping ایجاد کند و کلاس‌ها را به صورت خودکار Load کند.
آیا Laravel از Composer استفاده می‌کند؟
بله. Composer یکی از ابزارهای اصلی مدیریت Dependency در پروژه‌های Laravel است.
آیا Composer فقط برای Laravel است؟
خیر. Composer برای پروژه‌های PHP مستقل از Framework نیز قابل استفاده است.
# مقالات مرتبط
برای لینک‌سازی داخلی این مقاله، پیشنهاد می‌کنم این صفحات را به صورت طبیعی به یکدیگر متصل کنی:
- Namespace در PHP چیست؟
- آموزش Composer
- Autoload در PHP
- OOP در PHP
- Class و Object در PHP
- Interface در PHP
- Dependency Injection در PHP
- SOLID در PHP
- Design Pattern در PHP
- REST API با PHP
- ساخت API با PHP
همچنین از این مقاله حتماً یک لینک به Pillar اصلی «آموزش برنامه نویسی وب و PHP» قرار بده.
