Do not use Illuminate Support

tl; dr : If you are writing a framework agnostic package, do not use illuminate / support .

Translation of Matt Allan's " Don’t Use Illuminate Support " article .

Many agnostic Composer package packages (PHP) are dependent on illuminate / support , which includes helpers and general-purpose code used in the Laravel framework. And all because this package contains many great features like array_get, as well as great collections .

Helpers are a great thing, but I don’t think that developers understand all the consequences of including this package in their project. Everyone is afraid of criticism for the invention of the bicycle, so they pull 6,000+ lines of code so that they themselves do not write such code

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

Addiction hell

Using illuminate / support (5.2) you pull illuminate / contracts, doctrine / inflector, polyfill for random_bytes, and mb_string into your project. Fortunately, the dependency tree ends here.

Version conflict

Over 6,000 packages depend on illuminate / support. If someone installs your package and another, which includes illuminate / support, it must be dependent on the same version, otherwise it will result in a conflict. A quick glance shows that many projects still use version 4.1.x.

The situation worsens if your package is used together with Laravel or Lumen. The user will not be able to upgrade before you (and all packages using illuminate / support). Now you are stopping the user from updating their framework. The only alternative is to use unlimited ranges like >5.2, but this is a pretty bad idea.

Global scope

illuminate / support pulls 52 functions into the global scope. It’s good if the framework used does not use a namespace. Dependencies should not pollute the global area.

But helpers are great, why not use them? Some transformers do not work as expected , but are dduseless in the terminal . But everyone wants these 52 functions to behave as they want, so they put them in a global area.

Facades

This is of course a small problem, but it’s very annoying when you write the code 40+ hours a week. illuminate / support has many commonly used classes like Collection, Request, Response, and App. Every time I start typing a namespace, the IDE tries to import the wrong collection or useless facade instead of the actual class that I need. illuminate / support includes a whole catalog of classes that don't even work outside of Laravel! I guarantee that you do not use facades within the framework of agnostic, so please stop pulling them into my project.

Critical errors

Your package now depends on 3 different packages that do not violate SemVer. Should I risk getting the same problems as with the left-pad instead of writing a few lines of code?

Targeting fewer dependencies

Try to use as few dependencies as possible. If you look at projects from phpleague , you can see that they all have a small number of dependencies or do not have them at all. Good practice is to write some small helper classes for 2 or 3 functions. If you do not want to write yourself, copy the functions that you need in accordance with the license.

If you test all possible versions , it will take a lot of time to configure the CI server than to write your own code and tests for several auxiliary functions.

Alternatives

If you need a ton of functionality, you should use packages instead of writing everything yourself. Since illuminate / support covers a huge amount of functionality, below is a list of those that can be used for each specific case.

doctrine / inflector

Reduction of words to singular and plural. This is actually the illuminate / support dependency.

danielstjules / Stringy

Covers all string conversion functions. Used in illuminate / support up to version 5.2.

dusank / knapsack

Work with collections. The only packages I have found are comparable to the Laravel collections.

anahkiasen / underscore-php

Replacing functions for working with arrays uses dot notation. I don’t know a good alternative that supports point without using dependencies. I am just writing vanilla php for this. In php7 +, you can use the null coalesce operator instead array_get.