The modern PHP developers toolbox

There are a lot of tools available to a developer these days. Some are well known, but there are also some diamonds in the rough. So today, we are gonna look at some of the tools a modern (PHP) developer should use. A lot of these tools aren’t specific to PHP, so even if you are using another language, this may be worth checking out.

Dependency manager

I’d like to think that most projects these days use composer these days. It has been the standard for PHP development for the past few years. Managing your dependencies is easy now!

A problem before composer what that you had to include all 3rd party code manually. And if that code has a dependency on another package you had to include that as well. Then if multiple package depended on the same package you needed to make sure you only had 1 version of that package, and the correct one. Composer does all of that for you through your composer.json in the project.

This file specifies the version ranges your project (or package) can work with, and then installs the best versions of all packages according to all the constraints that each package has. Doing so produces a composer.lock file as well, which ’locks’ you into the specific dependency versions you install. This means that wherever you install this project, as long as you have the same composer.lock, the same dependencies get installed.

Now if newer versions of the packages you use get published, you can run composer update to update to the latest versions. You can do so locally, test the changes, and then you only have to push the new composer.lock in order for the newer versions to install on production.

Code style fixer

I’d like to note that i’m talking about a fixer here, not a linter. There is a small difference, but to me the result is huge. A linter will simply tell you all the errors you have, a fixer will fix then (automatically) for you.

One thing that annoys me to no end is a tool that tells me a bracket should be on a new line. If the tool knows that the bracket is in the wrong position, and it knows the correct position, it should change it for me. There should also be the option to run it without actually fixing the issues, to be used in a CI environment for example.

The fact that PHP-CS-fixer only has ‘rules’ that it can automatically fix, makes it my favorite fixer. Every error it will tell you about is one it can fix automatically. Do you want to adhere to PSR-2? simply add the @PSR2 rule to the configuration, and the next time your the fixer, your code will be PSR-2 styled. The fact that every issue also needs to be fixable does make it more limited in what it can detect.

Another great fixer is PHP_CodeSniffer. It comes with 2 commands: phpcs and phpcbf. The first command, phpcs which finds all errors and reports them to you. The second command is phpcbf, which fixes all the errors it can, and reports the other errors to you. This means that it can be a fixer for all the issues it can solve, but still allow more complex rules, that can’t be automatically fixed. If you want a strong set of rules I’d suggest the Doctrine coding standard. These are a set of rules, used in the doctrine projects, that uses PSR-2 as its baseline, but adds a whole lot of extra rules that help you write maintainable code.

Static analyzer

The previously mentioned tools aren’t ‘modern’ per se, but they are still ever evolving. Static analysis however, is relatively new in the PHP-scene. PHPStan saw its initial release on 2016-07-16. PHAN saw its first release on 2015-12-03. And Psalm became open source on 2016-11-21.

Static analysis is in essence a type checker. But with the big benefit, of not having to run the code to find out if it works. This means that in order to use a static analysis tool, you don’t have to write tests to execute the code. Take a look at the following example:

<?php

function sayHello(): int
{
    return 'hello';
}

/**
 * @return int
 */
function sayGoodbye()
{
    return 'good bye';
}

Now the first function will crash the moment it runs. The second function however, will run normally without crashing. Except that you think you have an integer, when in reality you are dealing with a string. Running a static analyzer, both of these functions will generate an error, without executing any line of code. And because it does to without needing to execute(run) the code, it can do so for the entire code base, without needing to write any tests.

The more you use type hints, whether its in comments or in code, the more static analysis will do for you. Most of these tools work with levels, where the higher levels will be more strict about your code. For example, it will tell you that your getcwd() may return false under specific circumstances, meaning you need to check for that. Static analysis helps you with more defensive programming.

These days my goto tool is PHPStan. It has extensions for frameworks, and allows for easy configuration by using the levels it provides. I have also been using Psalm as of late which seems to have a lot more options for specifying array/iterable types. I don’t have much experience with PHAN, but its focus lies on reducing false positives, and has more tooling for checking supported php versions.

And honorable mention also goes out to Exakat, which has a lot of focus on checking against certain types of php-versions. It also checks against common mistakes and code smells.

Static analysis is easy to set up, and the minimum levels are usually not a lot of effort to fix. Starting with static analysis can give you some quick-wins, and help you write more maintainable, robust code.

Unit testing framework

Yes you need to test your code.

The biggest php unit testing framework is PHPUnit. It allows you to set up your test conditions, execute the code, and then assert if everything is working correctly.

Unit testing on is a big topic on its own which will be covered in another upcoming blog-post

Mutation testing framework

I covered mutation testing, or more specifically infection in a previous blog-post, which I would recommend you to read. It is rather new, just like static analysis. Humbug saw its first pre release on 2015-05-25. And infection had its 0.1.0 release on 2017-07-01. Humbug has since been deprecated in favor of infection.

Mutation testing is an extension of unit testing. It is an extra layer on top of your mutation testing that makes sure your tests are catching the things they need to. Mutation testing is ’testing your tests’.

Editorconfig

Okay, this one isn’t really a tool of modern PHP developers, but I like editorconfigs, and its my blog.

Editorconfigs are a configuration file that you add to (the root of) your project, which tell your editor what kind of indenting to use where etc. It also tells your IDE whether or not to insert a final new line, clean up trailing white space etc.

Its configured in an ini like matter, and most IDE’s honor it out of the box, but some need a plugin/extension in order to use it. I’d reccomend checking out the editor config website to see all the options and how to use it.

Closing thoughts

This isn’t a full list of the tools you should be using, and some tools may be useless in your project or setting. I do consider this to be a baseline of tools I would use for any project. I didn’t include IDE’s or version control like git, but i do consider those vital.

Do you have tools you consider vital for development that aren’t mentioned here? Or do you disagree with the tools mentioned here? Let me know by leaving a comment, or by sending me a DM on twitter.