The PHP Tools I Actually Use in 2026 (and What I Dropped)

People ask me what PHP tools I run, usually after they’ve seen a five-year-old blog post with a list of 40 editors nobody touched. So here’s the honest version. This is the stack I actually reach for on client work, why each piece earned its spot, and a few popular tools I stopped bothering with.

I’ve been writing PHP since the 4.x days, mostly building and maintaining custom web development for small businesses and agencies. The list below is what survived years of me getting annoyed at things.

The editor and IDE question

I use PhpStorm. It’s paid, and I don’t care. The PHP-specific intelligence is the reason: it understands your codebase’s types well enough to catch real mistakes before you run anything, and its refactoring tools don’t mangle your files. If you’re on a budget, VS Code with the Intelephense extension gets you most of the way there. I’ve used both. PhpStorm saves me enough time per month to justify the license, but VS Code is genuinely fine and I won’t pretend otherwise.

One thing that matters more than which editor you pick: set up a real debugger. Xdebug with step debugging in your IDE beats var_dump() and die() every single time, especially on code you didn’t write.

Composer is non-negotiable

If you’re still copying library folders into your project by hand, stop. Composer is the dependency manager for PHP and it’s been the standard for over a decade. The lock file is the part people get wrong. Commit composer.lock to version control so every environment installs the exact same versions:

composer install --no-dev --optimize-autoloader

Use composer install in deployment (it respects the lock file). Use composer update only when you deliberately want to move versions forward, and then test. I’ve watched production break because someone ran update on the server. Don’t do that.

Static analysis: PHPStan or Psalm

This is the biggest quality upgrade most PHP codebases are missing. Static analysis reads your code without running it and finds type errors, dead code, and calls to methods that don’t exist. I run PHPStan at a meaningful level on everything now.

composer require --dev phpstan/phpstan

vendor/bin/phpstan analyse src --level=6

Start at level 0 or 1 if your codebase is old and messy, then raise the level over time. Going straight to level 8 on legacy code will bury you in thousands of errors and you’ll quit. I’ve done exactly that and learned my lesson. Psalm does the same job and is a fine alternative; pick one and actually run it in CI.

Testing with PHPUnit (and Pest if you like it)

PHPUnit is still the default test framework. Pest is a layer on top of it with cleaner syntax, and a lot of newer projects prefer it. Both run the same underlying engine, so this is mostly a taste decision.

composer require --dev phpunit/phpunit

vendor/bin/phpunit --testdox

The tool matters less than the habit. A handful of tests around your money paths (checkout, login, anything that writes to the database) will catch more bugs than a fancy setup you never run.

Formatting and code style

PHP CS Fixer or Pint handles formatting so you stop arguing about it in code review. Pint ships with Laravel but works standalone. Run it as a pre-commit hook or in CI and let the machine decide where the braces go.

vendor/bin/pint --dirty

# or with PHP CS Fixer
vendor/bin/php-cs-fixer fix src

What I stopped using, and why

• Heavyweight frameworks for small sites. If a project is a contact form and five pages, a full framework is more maintenance than the site is worth. Plain PHP with Composer and a router is easier to hand off.
• Abandoned packages. Before adding any dependency, check the last release date and open issue count. A package with no commits in three years is a liability, even if it works today.
• Local dev via FTP or editing on the server. Docker or a local stack (Laravel Herd, DDEV, or just PHP’s built-in server) means you test before you ship. Editing live is how you take a site down at 2pm on a Tuesday.

A note on PHP versions

Run a supported version. As of 2026 that means PHP 8.2 or newer; 8.3 and 8.4 are the safer choices for a new project, and 8.1 is past its security support window. Upgrading is usually less painful than people fear, and the performance and type improvements in the 8.x line are real. If your host is stuck on 7.x, that’s a hosting problem, not a PHP problem.

FAQ

Do I need paid tools to write good PHP?

No. VS Code, Composer, PHPUnit, and PHPStan are all free and cover the essentials. PhpStorm is worth the money if you code every day, but it’s a convenience, not a requirement.

What’s the single best upgrade for a messy legacy codebase?

Add PHPStan at a low level and get it running in CI. It surfaces real bugs without requiring you to rewrite anything, and you can tighten the level gradually as you clean things up.

Is PHP still worth learning in 2026?

Yes. It powers a huge share of the web, WordPress and Laravel are both thriving, and there’s steady demand for people who can maintain and modernize existing sites. It’s not the shiniest language, but it pays the bills.