Як створити PHP пакунок

6 хв. читання

Протягом багатьох років, PHP щосили намагався не відставати від інших мов, в зв'язку з відсутністю сумісності коду та загальних стандартів сумісності. Також, обираючи якийсь певний фреймворк, Ви застрягали в його кодовій базі без можливості замінити окремих складових.

Проте, протягом кількох останніх років, PHP пережив певне відродження. Спільнота обрала Composer в якості менеджера пакунків і ми можемо побачити багато справді чудових пакунків, незалежних від фреймворків. Більше того, з прекрасними останніми версіями таких фреймворків, як** Laravel** та Symfony, що зпроектовані за цими принципами сумісності, Ваш вибір, як PHP-розробника, ще ніколи не був таким великим.

До того ж, як я вважаю, у PHP попереду довгий шлях, і він йде йде в ногу з новими технологіями.

В цій статті, я розповім про базові принципи та деякі важливі для розуміння речі, необхідні при створенні PHP пакунка.

Інструменти Open Source

Ще ніколи не було кращих часів для створення Open Source програмного забезпечення, як зараз, з тими інструментами й системами для поширення і спільної праці над кодом які доступні нам. Як розробник Open Source програмного забезпечення на PHP, Ви маєте бути знайомі з трьома речима.

Composer

Як згадувалось раніше, Composer є широко розповсюдженим в спільноті PHP пакетним менеджером. Composer робить додавання сторонніх пакунків в Ваш проект справді простим і дозволяє підтримувати ці пакунки при виході оновлень.

Packagist

Packagist є основним архівом PHP пакунків, де Ви можете переглянути доступні для Composer пакунки.

На мою думку, однією з рис хорошого розробника є спроба не винаходити колесо. Перше місце, куди я дивлюсь при виникненні специфічної проблеми яку необхідно вирішити -- це Packagist, де хтось, її, можливо, вже вирішив.

Створивши одного разу свій PHP пакунок, Ви можете надіслати його до Packagist, аби інші розробники могли його знайти та використати.

Github

Github, протягом кількох останніх років, став дивовижним середовищем для Open Source програмного забезпечення. Github дозволяє викласти в вільний доступ Ваш відкритий репозиторій та надає кілька дивовижних інструментів для спільної роботи, як, наприклад, запитання (issues), запити на включення (pull requests) та вікі-документація, а також цілий ряд соціальних інструментів, які мають пряме відношення до сумісного написання коду.

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

Стандарти сумісності PHP

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

PHP FIG \- це група розробників які представляють різні проекти та приймають ініціативи в світі PHP. Ця група прагне прийняти стандарти за якими код на PHP має писатися з дотриманням сумісності.

Починаючи з 2009-го року, група ввела п'ять стандартів, а саме:

PSR-0 -- має за ціль вказати стандартні файли та домовленості щодо найменування класів і просторів імен з ціллю забезпечення умов для створення легкого в перенесенні коду.

PSR-1 -- має на меті забезпечити високий рівень технічної сумісності між поширюваним кодом.

PSR-2 -- надає керівництво по оформленню коду для проектів, для його стандартизації.

PSR-3 -- описує загальний інтерфейс для бібліотек, що відповідають за логування.

PSR-4 -- визначає загальний метод автозавантаження пакунків.

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

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

Структура пакунку

Остання важлива річ яка має залишитись у Вас в голові -- яку структуру має мати пакунок. Згідно прийнятого стандарту, ми не лише переконуємось, що все працює правильно, але й кожен може негайно дізнатися де знайти те що шукає коли вперше знайомишся з кодом пакунка.

Для того щоб проілюструвати структуру PHP пакунка, давайте подивимось на пакунок Plates.

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

Ви помітите дві директорії -- _**src**_ та _**test**_. В директорії _**src**_ ми зберігаємо актуальний вихідний код пакунка, а в директорії _**test**_ -- всі тести.

Якщо Ви зайдете в директорію src то побачите код пакунка. В PSR-4, фактично, змінилась структура пакунку. Раніше, Ви б знайшли тут директорію League, а потім Plates, але тепер більше не потрібно мати зайві каталоги. Проте, багато пакунків не перейшло на нову структуру.

Простір імен

Коли Ви вперше подивитесь на PHP пакунок, може здатися дещо надлишковим -- мати всі ці поодинокі каталоги. Однак ця структура є дуже важливою для сумісної роботи пакунків.

Якщо Ви подивитесь на PSR-0 то побачите, що ми зобов'язанні використовувати простір імен Vendor\\Namespace\\File. Як можна побачити в пакунку Plates, League - це назва вендора (розробника), а Plates - це простір імен.

Чому це важливо? Ми повинні використовувати простір імен для коректності коду та запобігання конфліктів. Простір імен гарантує, що ми обираємо правильний клас, коли два класи мають однакові імена.

Висновки

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

Помітили помилку? Повідомте автору, для цього достатньо виділити текст з помилкою та натиснути Ctrl+Enter
Codeguida 1.2K
Приєднався: 1 рік тому
Коментарі (2)
  1. p.s.

    Напишу простіше:

    1. composer init
    2. git commit -m 'init composer package'
    3. git push

    Система сумісності новачкам не треба, стандартно composer init запропонує актуальну версію PSR на момент створення проекту.

    Що б я дійсно порадив то це ознайомитись з основами https://semver.org/lang/uk/

    5 місяців тому ·
    0
  2. p.s.
    Перше місце, куди я дивлюсь при виникненні специфічної проблеми яку необхідно вирішити -- це Packagist, де хтось, її, можливо, вже вирішив.

    Ніколи не відвідую Packagist хіба що коли мені треба оновити API для пакунків. Хіба там є баг трекер? Packagist - це просто резольвер для Composer. Весь двіж на GitHub чи іншому сховищі, на який Packagist лінкує пакунок.

    5 місяців тому ·
    0
Щоб залишити коментар необхідно авторизуватися.

Вхід