Composer - повний огляд розширених можливостей

Як ви вже знаєте, [Composer](https://getcomposer.org/) - це надійний менеджер пакетів і залежностей для PHP, за допомогою якого можна елегантно керувати сотнями проектів одночасно і поширювати один раз написаний код в усі додатки одночасно.

Цей посібник є детальним всеосяжним керівництвом для розробників. Ми розглянемо всі важливі сучасні прийоми роботи з Composer, а також пояснимо технічні деталі та відповідні залежності.

Встановлення композитора

Незалежно від платформи, завантажуємо з [офіційного сайту Composer] (https://getcomposer.org/).

Всередину завантажується PHP-файл composer-setup.php, який при запуску в режимі CLI може встановити Composer. Також важливо знати, що Composer не працює без PHP, тому спочатку переконайтеся, що на вашому комп'ютері працює PHP (він повинен бути доступний тільки для Терміналу).

На Mac і Linux Composer працює відразу після інсталяції, і вам просто потрібно викликати команду composer -v, щоб швидко перевірити, що Composer встановлений правильно.

В Linux для встановлення можна використовувати наступну команду: /usr/bin/php -r "copy('https://getcomposer.org/installer', 'composer-setup.php');".

У Windows добре встановити інструмент Git Bash для Windows, який дозволяє відкрити специфічний термінал, який поводиться майже як Linux і дозволяє працювати в тому ж середовищі, що і в Linux.

Встановлення для серверів відбувається так само, як і в локальному середовищі. Просто переконайтеся, що у вас встановлена правильна версія PHP, яку Composer використовує всередині.

Доступні команди

Композитор реалізує ряд команд.

Використання: composer <команда>, наприклад: composer update.

Огляд за 1.10.0:

Створення та визначення проекту

Кожен проект, керований Composer, визначається файлом composer.json в його корені, який визначає всі залежності. Файл може бути створений як вручну для існуючого проекту, так і автоматично при створенні проекту.

Оскільки в Composer все є пакетом, то і сам проект може базуватися на пакеті. Так, наприклад, якщо ви створюєте десятки або сотні дуже схожих проектів, має сенс винести їх базову конфігурацію і структуру в окремий пакет, на якому базувати інсталяцію.

Прикладом такого пакету є мій Baraja Sandbox, який базується на чистому Nette 3.0 і додає базову залежність до мого Package Manager, який я використовую для всіх проектів та управління залежностями в конфігурації Nette.

Потім пісочниця встановлюється просто за допомогою команди:

$ composer create-project baraja/sandbox <your-project-name>

На основі назви проекту Composer автоматично створить папку для інсталяції проекту (скопіює вміст пакунків та встановить залежності).

У папці vendor Composer потім керує всіма пакетами (їх фізичні файли знаходяться там) і генерує автозавантаження класів, які ми в ідеалі поміщаємо безпосередньо в index.php у вигляді рядка:

require __DIR__ . '/vendor/autoload.php';

// Сам код програми

Встановлення додаткових пакетів та залежностей

В рамках функціонального проекту ми можемо дуже легко встановлювати нові пакети та додавати залежності.

Для цього є 2 шляхи:

• За допомогою команди composer require ...,
• Шляхом додавання залежності безпосередньо до файлу composer.json в розділі require, а потім за допомогою команди composer update.

Спробуйте встановити наприклад PackageManager: composer require baraja-core/package-manager, або Doctrine: composer require baraja-core/doctrine.

Якщо вибраний пакунок не вдається встановити, можна запитати про конкретні причини, і Composer видасть список залежностей, які перешкоджають цьому. Часто достатньо виправити залежність від конкретної версії або видалити несумісний код. Для отримання детальної інформації скористайтеся командою: composer why baraja-core/doctrine.

Оновлення проектів та пакетів

Добре продуманий проект розроблений таким чином, щоб ви могли легко завантажувати оновлення з плином часу і завжди мати найновіші версії всіх пакетів. Основна перевага полягає в тому, що ви отримуєте виправлення всіх помилок, часто покращення продуктивності та багато нових функцій. Крім того, поступовий перехід зробить оновлення менш складним через тривалий час, оскільки ви будете виправляти проблеми на льоту в менших масштабах і уникати несумісності.

Для оновлення всіх пакетів і залежностей використовуйте команду composer update.

Сам процес оновлення в деяких випадках може завершитися зі збоями. Причиною зазвичай є або порушена залежність, або несумісний пакет.

Для отримання детальної інформації про те, чому не вдається встановити пакет, скористайтеся командою: composer why-not baraja-core/doctrine. Якщо у нас вже є пакет і не працює тільки конкретна версія (не хоче встановлюватися), ми також можемо попросити конкретну версію: composer why-not baraja-core/doctrine:v1.0.20.

У файлі composer.json ми також можемо перерахувати залежність від конкретного часу виконання. Це особливо корисно, коли ми розробляємо проект з кількома людьми і хочемо перевірити, що у них встановлені всі розширення.

Як правило, перевіряється версія PHP (повинна бути не нижче 7.1.0):

{
   "require": {
      "php": ">=7.1.0"
   }
}

Можливі й інші розширення системи:

{
   "require": {
      "php": ">=7.1.0",
      "ext-json": "*",
      "ext-session": "*",
      "ext-PDO": "*"
   }
}

Ці правила потім враховуються при встановленні пакетів або оновлень. Це допомагає запобігти проблемам, які могли б проявитися під час виконання програми. Зазвичай, наприклад, пакету платіжного шлюзу необхідно взаємодіяти з API, тому він повинен допускати залежності від розширень curl та json.

Пошук та усунення несправностей залежностей

Часто порушення залежностей виникають через погану версію PHP. У цьому випадку Composer видає повідомлення, наприклад, "ваша версія PHP (7.3.11), перевизначена версією "config.platform.php" (7.1), не задовольняє цій вимозі".

Дуже часто помилка викликана налаштуваннями безпосередньо в проекті composer.json, де знаходиться наступна секція:

"config": {
   "platform": {
      "php": "7.2"
   }
}

Зміна повинна бути внесена безпосередньо у файлі. У разі глобального проекту (перед установкою або з глобальною залежністю) можна примусово встановити версію Composer за допомогою composer config -g platform.php 7.2.14 (перемикач -g означає global).

У деяких випадках ми хочемо встановити найновіші версії пакетів та ігнорувати налаштування локального середовища. У цьому випадку ми можемо скористатися розширеною командою:

$ composer update --ignore-platform-reqs

**Використовуйте перемикач ignore-platform-reqs на свій страх і ризик, він може завдати шкоди проекту! Не використовуйте його, якщо не розумієте наслідків.

Виклики, параметри та управління пам'яттю ручного композитора

Composer - це фактично PHP-скрипт, загорнутий у так званий PHAR, який є скомпільованою версією PHP-додатку. Знання цієї інформації може бути використане з користю, наприклад, для кращого визначення параметрів самого виклику.

У дійсно великих проектах іноді трапляється так, що у нас закінчується оперативна пам'ять і потрібно виділяти набагато більше, або збільшувати час обробки скриптів.

Наприклад, в Windows для цього можна скористатися такою командою:

$ php -d memory_limit=-1 C:/xampp/htdocs/composer.phar update

Ключ memory_limit=-1 вказує Composer не зважати на обмеження оперативної пам'яті і використовувати стільки пам'яті, скільки йому потрібно.

Користувацькі сценарії після дії Composer

Після запуску дій Composer можна викликати автоматичне виконання визначених користувачем скриптів, які або виконують певні дії над проектом, або, наприклад, генерують конфігурацію після розгортання. Я в основному використовую цей підхід на локальному сервері, щоб запропонувати інструмент автоматичної конфігурації бази даних, генерування схеми бази даних і так далі.

Прописуємо необхідні скрипти в розділі skripts файлу composer.json:

"scripts": {
   "post-autoload-dump": "Baraja\\PackageManager\\PackageRegistrator::composerPostAutoloadDump"
}

При цьому автоматично викликається статичний метод composerPostAutoloadDump в класі Baraja\PackageManager\PackageRegistrator. Composer має цей клас, тому що він першим виконав генерацію класів автозавантажувачів.

Якщо ми хочемо просто запустити скрипти і не виконувати зайвих дій з Composer, то команда composer dump дуже корисна, так як вона просто генерує новий автозавантажувач (який я рекомендую завжди тримати в актуальному стані), а потім відразу запускає скрипти. Якщо ви хочете спробувати використовувати скрипти, я підготував готовий пакет [Baraja PackageManager] (https://github.com/baraja-core/package-manager), який реалізує розумні скрипти та інтерактивний інтерфейс для фреймворку Nette.

Версіонування Vendor в Git?

Питання, яке ми часто обговорюємо з розробниками, полягає в тому, чи слід версіонувати вміст папки vendor в Git'і, або ж генерувати її заново при кожній установці.

Загалом, більш чистим рішенням, здається, було б не версіонувати вміст взагалі і встановлювати все щоразу. Але реальність така, що час від часу розробник припиняє розробку пакета, або взагалі видаляє його. Постійне завантаження пакетів також ускладнює локальне встановлення та оновлення, а також уповільнює розгортання, а іноді може спричинити короткочасні перебої в роботі сайту, коли нові версії пакетів завантажуються некоректно.

Я розглядаю відсторонення Постачальника як форму "безпеки". Якщо файли фізично знаходяться в системі версій, ми маємо хоча б елементарну гарантію на виробничому сервері, що пакети будуть працювати і їх код точно такий же, як і в локально запущеній інсталяції. Крім того, Вендор часто займає лише одиниці мегабайт, що, безумовно, є гарантією працездатності сайту, враховуючи сьогоднішні обсяги дискового простору.

Практичне зауваження: Для середньостатистичного сайту, який я обслуговую, "вендор" займає не більше "30 МБ", що є прийнятною ємністю для Git'а. При клонуванні сховища за допомогою junior, нам не потрібно мати справу з навчанням його тому, як запустити сайт, і він просто "працює відразу".

Пакети Custom Composer

Ви можете створювати власні пакунки у Composer, як загальнодоступні (зареєстровані на Packagist), так і приватні (ви повинні мати власний сервер пакунків, наприклад Satis).

Питання створення, супроводу, розвитку та версійності пакетів є дуже складним і буде темою окремої статті.

А поки що можете почитати статтю [Семантична версифікація] (https://semver.org/lang/cs/), яку я переклав для вас.

Jan Barášek   Více o autorovi

Autor článku pracuje jako seniorní vývojář a software architekt v Praze. Navrhuje a spravuje velké webové aplikace, které znáte a používáte. Od roku 2009 nabral bohaté zkušenosti, které tímto webem předává dál.

Rád vám pomůžu:

Kontakt