Не використовуйте Illuminate Support

tl;dr: Якщо Ви пишете framework agnostic пакет, не використовуйте illuminate/support.
laravel

Переклад статті Метта Аллана (Matt Allan) "don't Use Illuminate Support".
Безліч framework agnostic Composer пакетів (PHP) залежать від illuminate/support, який включає в себе хелпери та код загального призначення, що використовується в Laravel framework. А все тому, що даний пакет містить в собі безліч чудових функцій типу
array_get
, а також чудові колекції.
Хелпери — відмінна штука, але я не думаю, що розробники розуміють всі наслідки включення даного пакету в свій проект. Всі бояться критики за винахід велосипеда, тому тягнуть 6000+ рядків коду, щоб самим не писати такий код
isset($arr[$k]) ? $arr[$k] : null

Ад залежностей
Використовуючи illuminate/support (5.2) Ви підтягуєте в свій проект illuminate/contracts, doctrine/inflector, полифилл для random_bytes, і mb_string. На щастя дерево залежностей на цьому закінчується.
Не для слабкодухих. Цей абзац є виключно висновками самого автора.mb_string не стандартний php модуль, тому він не може бути встановлений на машині користувача. Якщо Ви не працюєте з рядками, не варто змушувати користувачів перекомпілювати PHP тільки для того, щоб використовувати свій пакет. Можете використовувати stringy як хорошу альтернативу, він використовує полифилл.
Конфлікт версій
Більше 6000 пакетів залежать від illuminate/support. Якщо хто-небудь встановить Ваш пакет і іншого, що включає в себе illuminate/support, він повинен бути залежним від тієї ж версії, інакше вийде конфлікт. Побіжний погляд показує, що безліч проектів все ще використовують версію 4.1.x.
Становище погіршується, якщо Ваш пакет використовується разом з Laravel або Lumen. Користувач не зможе оновитися раніше Вас (і всі пакети, які використовують illuminate/support. Тепер Ви заважаєте користувачеві оновити свій фреймворк. Єдина альтернатива, використовувати необмежені діапазони зразок
>5.2
, але це досить погана ідея.
Глобальна область видимості
illuminate/support підтягує 52 функції в глобальну область видимості. Добре якщо використовується фреймворк не використовує простір імен. Залежно не повинні забруднювати глобальну область.
Але ж хелпери прекрасні, чому б не використовувати їх? Деякі трансформери працюють не так, як очікується, а
dd
даремний в терміналі. Але чи всі хочуть, щоб ці функції 52 вели себе так, як хочеться, тому пхають їх у глобальну область.
Фасади
Це звичайно невелика проблема, але сильно дратує коли пишеш код за 40+ годин в тиждень. illuminate/support має безліч часто використовуваних класів типу Collection, Request, Response, і App. Кожен раз, коли я починаю набирати простір імен, IDE намагається імпортувати неправильну колекцію або даремний фасад замість фактичного класу, який мені потрібен. illuminate/support включає в себе цілий каталог класів які навіть не працюють за межами Laravel! Я гарантую, що Ви не використовуєте фасади в рамках framework agnostic, тому, будь ласка, припиніть тягнути їх в мій проект.
Критичні помилки
Зараз ваш пакет залежить від 3-х різних пакетів, що не порушують SemVer. Варто ризикувати отримати такі ж проблеми як з left-pad замість написання декількох рядків коду?
Націлювання на меншу кількість залежностей
Спробуйте використовувати як можна менше залежностей. Якщо подивитися на проекти від phpleague, то можна помітити, що всі вони мають малу кількість залежностей або взагалі їх не мають. Хороша практика — написати кілька невеликих допоміжних класів для 2-х або 3-х функцій. Якщо не хочеться писати самостійно, скопіюйте функції, які Вам потрібні згідно з ліцензією.
Якщо тестувати всі можливі версії, багато часу піде на налаштування конфігурації CI сервера, ніж на написання власного коду і тестів для декількох допоміжних функцій.
Альтернативи
Якщо Вам потрібна тонна функціоналу, слід використовувати пакети замість того, щоб все писати самому. Оскільки illuminate/support охоплює величезну кількість функціоналу, нижче список тих, що можна використовувати для кожного конкретного випадку.
doctrine/inflector
Приведення слів до єдиного і множинного числа. Це насправді залежність illuminate/support.
danielstjules/Stringy
Охоплює всі функції перетворення рядків. Використовувався в illuminate/support до версії 5.2.
dusank/knapsack
Робота з колекціями. Єдині пакет, знайдений мною порівнянний з Laravel collections.
anahkiasen/underscore-php
Заміна функцій для роботи з масивами, використовує точкову нотацію. Я не знаю, хорошою альтернативи, підтримуючої точкову без використання залежностей. Я просто пишу ванільний php для цього. У php7+ null coalesce operator замість
array_get
.
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.