Every two weeks I send out a newsletter containing lots of interesting stuff for the modern PHP developer. You can expect quick tips, links to interesting tutorials, opinions and packages. Want to learn the cool stuff? Then sign up now!

Why we are requiring PHP 7 for our new packages

The past few weeks we released several new packages: laravel-sluggable, laravel-robots-middleware, laravel-glide and pdf-to-text. These packages have in common that they all require PHP 7. Because there were several reactions and questions about this, I’d like to shed some light on that decision.

I expect that lots of developers will make the move to PHP 7 in the coming year. Sure there will always be legacy projects that’ll never see an upgrade, but it makes no sense starting a greenfield project in PHP 5.X. The performance benefits are just too good. On the package side I expect that some widely used packages will make the jump as well.  Jordi Boggiano has already announced that the next version of Monolog targets PHP 7. Also keep in mind that active support for PHP 5.x is coming to end this August (or at the latest December).

Not only developers will make a quick move to PHP 7. The speed benefit is quite interesting for hosting companies as well. A speedier PHP version means a machine can host more sites. There quite a few hosting companies that already made the jump and are offering PHP 7 support.

When we work on projects at Spatie we have to solve a lot of problems. When we solve a problem in way that the solution can be used in future projects, we create a package. So we create these packages primarily for our own future projects. We decided that from now on every greenfield project wil be a PHP 7 one. So it makes sense that our new packages would require PHP 7 as well. By doing so we can make use of the latest new features such as the scalar type hints, return types, anonymous classes and the null coalescing operator. At some point all our projects will leave PHP 5.6 behind. The earlier we won’t have to deal with PHP 5.X code anymore the better.

I’m well aware that requiring PHP 7 will hurt the popularity of our packages in the short run. But popularity is not our main goal. People who are using the latest and greatest version of PHP can benefit from our work. And I hope others will be nudged a bit towards PHP 7 by our decision.

(EDIT: we won’t change the requirements of our older packages. PHP 7 will only be required when we create a new major version.)

Freek Van der Herten is a partner and developer at Spatie, an Antwerp based company that specializes in creating web apps with Laravel. After hours he writes about modern PHP and Laravel on this blog. When not coding he’s probably rehearsing with his kraut rock band. He loves waffles and butterflies.
  • I think this is a great thing to be doing! The benefits of PHP7 make it worth it, and with the speed increases, *hopefully* web hosting companies will upgrade faster than they have in the past.

  • This is going to be a good thing for the future of PHP; it certainly makes sense to begin using PHP7’s features now if you have a hosting environment suited to it. We are currently running with PHP5.6 but would look to migrate over to PHP7 by Q1 2017 as upgrading legacy applications appears to be quite trivial (given the experience of those I have attempted to migrate so far.)

    I think the biggest issue stopping people from migrating is that a lot of linux flavours will not provide an easy method of installing through packages especially for those with LTS releases given that one flavour of RedHat LTS still ships with PHP 5.3 that they still support and patch…

  • This is really beautiful manifesto. I have the same approach for my packages, so I’m glad you summed it up!

  • Pingback: January 2016 Newsletter - Nomad PHP()

  • Pingback: A modern backup solution for Laravel apps | murze.be()

  • Pingback: PHP 7 usage at 20% according to Packagist stats - murze.be()

  • Pingback: PHP 7 is gaining ground fast - murze.be()

  • Pingback: Laravel 5.5 will require PHP 7.0+ - murze.be()

  • DigitalCoder

    I agree with you, it’s a good decision.
    I usually also recommends using the latest versions, latest releases.

    However, many of us do not have the ability to migrate their server to PHP 7.
    In particular, for my part, I do not have the possibility to administer my server which is at OVH.

    Currently, I can not install the version of laravel-analytics 2.4.0 in production.

    What I do not understand is that in local with PHP 5.6.27 laravel 5.2, I was able to install “spatie / laravel-analytics”: “2.3.1”
    No problem with my PHP version
    In local the only problem I encountered is in relation to my version of Laravel:

    Problem 1
    – Installation request for space / laravel-analytics 2.4.0 -> satisfiable by space / laravel-analytics [2.4.0].
    – Conclusion: remove laravel / framework v5.2.45
    – Conclusion: do not install laravel / framework v5.2.45
    – space / laravel-analytics 2.4.0 requires illuminate / support ~ 5.3.0 | ~ 5.4.0 -> satisfiable by illuminate / support [v5.3.0, v5.3.16, v5.3.23, v5.3.4, v5.4.0, V5.4.13, v5.4.9].
    – do not install illuminate / support v5.3.0 | do not install laravel / framework v5.2.45
    – do not install illuminate / support v5.3.16 | do not install laravel / framework v5.2.45
    – do not install illuminate / support v5.3.23 | do not install laravel / framework v5.2.45
    – do not install illuminate / support v5.3.4 | do not install laravel / framework v5.2.45
    – do not install illuminate / support v5.4.0 | do not install laravel / framework v5.2.45
    – do not install illuminate / support v5.4.13 | do not install laravel / framework v5.2.45
    – do not install illuminate / support v5.4.9 | do not install laravel / framework v5.2.45
    – Installation request for laravel / framework (v5.2.45, required as 5.2. *) -> satisfiable by laravel / framework [v5.2.45].

    Today, I do not really know what to do 🙁