Не используйте Illuminate Support

tl;dr: Если Вы пишете framework agnostic пакет, не используйте illuminate/support ^[1].

Множество framework agnostic Composer пакетов (PHP) зависят от illuminate/support ^[1], который включает в себя хелперы и код общего назначения, используемый в Laravel framework. А всё потому, что данный пакет содержит в себе множество замечательных функций ^[2] типа array_get, а также великолепные коллекции ^[3].

Хелперы — отличная штука, но я не думаю, что разработчики понимают все последствия включения данного пакета в свой проект. Все боятся критики за изобретение велосипеда, поэтому тянут 6000+ строк кода ^[4] чтобы самим не писать такой код

isset($arr[$k]) ? $arr[$k] : null

Ад зависимостей

Используя illuminate/support (5.2) Вы подтягиваете в свой проект illuminate/contracts, doctrine/inflector, полифилл для random_bytes, и mb_string. К счастью дерево зависимостей на этом заканчивается.

mb_string не стандартный php модуль ^[5], поэтому он не может быть установлен на машине пользователя. Если Вы не работаете со строками, не стоит заставлять пользователей перекомпилировать PHP только для того, чтобы использовать свой пакет. Можете использовать stringy ^[6] как хорошую альтернативу, он использует полифилл.

Конфликт версий

Более 6000 пакетов ^[7] зависят от illuminate/support. Если кто-нибудь установит Ваш пакет и другой, включающий в себя illuminate/support, он должен быть зависим от той же версии, иначе получится конфликт. Беглый взгляд показывает, что множество проектов всё ещё используют версию 4.1.x.

Положение ухудшается, если Ваш пакет используется вместе с Laravel или Lumen. Пользователь не сможет обновиться раньше Вас (и все пакеты, использующие illuminate/support). Теперь Вы мешаете пользователю обновить свой фреймворк. Единственная альтернатива, использовать неограниченные диапазоны вроде >5.2, но это довольно плохая идея.

Глобальная область видимости

illuminate/support подтягивает 52 функции ^[8] в глобальную область видимости. Хорошо если используемый фреймворк не использует пространство имён. Зависимости не должны загрязнять глобальную область.

Но ведь хелперы прекрасны, почему бы не использовать их? Некоторые трансформеры работают не так, как ожидается ^[9], а dd бесполезен в терминале ^[10]. Но все хотят, чтобы эти 52 функции вели себя так как хочется, поэтому суют их в глобальную область.

Фасады

Это конечно небольшая проблема, но сильно раздражает когда пишешь код по 40+ часов в неделю. illuminate/support имеет множество часто используемых классов типа Collection, Request, Response, и App. Каждый раз, когда я начинаю набирать пространство имён, IDE пытается импортировать неправильную коллекцию или бесполезный фасад вместо фактического класса, который мне нужен. illuminate/support включает в себя целый каталог классов ^[11] которые даже не работают за пределами Laravel! Я гарантирую, что Вы не используете фасады в рамках framework agnostic, поэтому, пожалуйста, прекратите тянуть их в мой проект.

Критические ошибки

Сейчас ваш пакет зависит от 3-х различных пакетов, не нарушающих SemVer. Стоит ли рисковать получить такие же проблемы как с left-pad ^[12] вместо написания нескольких строк кода?

Нацеливание на меньшее количество зависимостей

Попробуйте использовать как можно меньше зависимостей. Если посмотреть на проекты от phpleague ^[13], то можно заметить, что все они имеют малое количество зависимостей или вообще их не имеют. Хорошая практика — написать несколько небольших вспомогательных классов для 2-х или 3-х функций. Если не хочется писать самостоятельно, скопируйте функции которые Вам нужны в соответствии с лицензией.

Если тестировать все возможные версии ^[14], много времени уйдёт на настройку конфигурации CI сервера, чем на написание своего собственного кода и тестов для нескольких вспомогательных функций.

Альтернативы

Если Вам нужна тонна функционала, следует использовать пакеты вместо того, чтобы всё писать самому. Поскольку illuminate/support охватывает огромное количество функционала, ниже список тех, что можно использовать для каждого конкретного случая.

doctrine/inflector ^[15]

Приведение слов к единственному и множественному числу. Это на самом деле зависимость illuminate/support.

danielstjules/Stringy ^[16]

Охватывает все функции преобразования строк. Использовался в illuminate/support до версии 5.2.

dusank/knapsack ^[17]

Работа с коллекциями. Единственные пакет, обнаруженный мной сравнимый с Laravel collections.

anahkiasen/underscore-php ^[18]

Замена функциям для работы с массивами, использует точечную нотацию. Я не знаю, хорошей альтернативы, поддерживающей точечную без использования зависимостей. Я просто пишу ванильный php для этого. В php7+ можно использовать null coalesce operator ^[19] вместо array_get.

Оригинал ^[20]

Автор: enniel

Источник ^[21]