Do not use Illuminate Support

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

Translation of Mett Allan’s article “ Don't Use Illuminate Support ”.

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

Helpers are a great thing, but I don’t think that developers understand all the implications of including this package in your project. Everyone is afraid of criticism for the invention of the bike, so they are drawing 6000+ lines of code so as not to write such code

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

Hell addictions

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

Version conflict

Over 6000 packages depend on illuminate / support. If someone installs your package and another one, including illuminate / support, it must be dependent on the same version, otherwise there will be a conflict. A quick glance shows that many projects still use version 4.1.x.

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

Global scope

illuminate / support pulls up 52 functions to the global scope. It is good if the used framework does not use namespace. Dependencies should not pollute the global area.

But the helpers are beautiful, why not use them? Some transformers do not work as expected , and dd useless in the terminal . But everyone wants these 52 functions to behave as they want, therefore they are shoving them into a global area.

Facades

This is certainly a small problem, but very annoying when you write code for 40+ hours a week. illuminate / support has many commonly used classes such as 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 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 agnostic framework, so please stop pulling them into my project.

Critical errors

Now your package depends on 3 different packages that do not violate SemVer. Is it worth the risk to get 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 a few 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 set up a CI server configuration 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

The casting of words to the 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 package I have found is comparable to Laravel collections.

anahkiasen / underscore-php

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