Ramblings of a Tampa engineer
Desktop after work
Photo by Luca Bravo / Unsplash

A few weeks ago I was having just a regular PHP random discussion at a meetup about great PHP packages. I had mentioned Intervention is my absolutely favorite package for manipulating images in PHP.

I started really manipulating images via PHP around Halo 2 which was so long ago at this point. I was writing some seriously bad low level image manipulation code.

Unfortunately that code has been lost in time, but the one I wrote a few games later for Halo Reach still exists. I even blogged about this historical project.

$template = imagecreatefrompng(DOC_IPS_ROOT_PATH ."reach/templates/pack5-aqua.png");
$size = getimagesize(DOC_IPS_ROOT_PATH . "reach/templates/pack5-aqua.png");

imagecopy($template,$watermark,imagesx($template) - ($water_w) - 11 , imagesy($template) - ($water_h + 3), 0, 0, imagesx($watermark), imagesy($watermark));
imagestring($template, $this->fonts[0], 160, 40, $this->lang->words['inactive_1'], $black);
imagestring($template, $this->fonts[0], 160, 62, $this->lang->words['inactive_2'], $black);
ReachStats

A small snippet is above and this was complex to maintain or even remember how it worked. So below is how simple Intervention made everything.

Image::make('public/foo.jpg')
    ->resize(320, 240)
    ->insert('public/watermark.png')
    ->save('public/bar.jpg');
Intervention docs

So if we flash back to the discussion a friend was having with me - they said they didn't trust Intervention because it was abandoned and old. This struck a cord with me and led to this blog post. Which the intent is not to create some large post to debate a random discussion into the ground, but to research the hell out of some image manipulation libraries and learn some stuff.


So off to packagist to search for just "image" and start pulling packages and ignoring some that look unrelated.

All other top packages seem unrelated to manipulating images and more uploading, optimizing, organizing, etc.

So for those 5 packages up there I want to dig into what dependencies they use to see if they indeed support their own low level logic or use a different package for manipulating images.

➜  composer show --tree spatie/image       
spatie/image 2.1.0 Manipulate images with an expressive API
├──ext-exif *
├──ext-json *
├──ext-mbstring *
├──league/glide ^2.0
│  ├──intervention/image ^2.4
....

Right out of the gate, I saw something that was interesting. I was not aware that spatie/image used league/glide which actually used intervention/image. So that means 3 of the packages up there all basically use Intervention at the lowest level.

➜  composer show --tree imagine/imagine
imagine/imagine 1.2.4 Image processing for PHP 5.3
└──php >=5.3.2
➜  composer show --tree nette/utils    
nette/utils v3.2.5 🛠  Nette Utils: lightweight utilities for string & array manipulation, image handling, safe JSON encoding/decoding, validation, slug or strong password generating etc.
└──php >=7.2 <8.2

Both imagine/imagine and nette/utils appear to have their own low level code so there might only be 3 popular PHP packages that manipulate images.

You can see this with many popular frameworks and tools that chances are they depend on Symfony. Symfony runs behind the scenes for Drupal, Joomla, Magento, Laravel, Yii and many more.

This reminds me how so many things depend on OpenSSL, which only after some vulnerabilities did that project get the monetary and focus it needed.

I feel Laravel's ecosystem handles this very well. They depend on quite a few projects and every time a new PHP version arrives they start a pull request. They identify all the issues on packages they use and they don't complain and demand fixes from those packages - they contribute!

[6.x] Full PHP 8.0 Support #33388

PHP8 was a big jump for the sole reason that most packages that have version constraints did not consider 8 (and for good reason). So this meant the staff and contributors to Laravel spread out to all packages that Laravel depend on and got support working on many other packages.

At times when packages get archived (FakerPHP) this lead to a few folks from the Laravel organization joining other notable names in the industry to fork that package and keep it moving on - https://github.com/FakerPHP/Faker/.

I do appreciate that behavior from Laravel to keep the ecosystem healthy, which I don't think can be said to be true about everything. I see this healthy behavior as well from TryGhost in the NodeJS ecosystem so I know its in the best interest of all large projects to also support everything upstream. If only every contributor of anything open source also felt that way.

You’ve successfully subscribed to Connor Tumbleson
Welcome back! You’ve successfully signed in.
Great! You’ve successfully signed up.
Your link has expired
Success! Check your email for magic link to sign-in.