You should be using PHPStans bleeding edge

Does your project use PHPStan? Then you really should be using the bleeding edge config, regardless of what level you are running. It will make transition to the newer version much easier.

What is bleeding edge

To preserve backwards compatibility as much as possible, new rules, and new settings are delayed until the next major version. For example, using null coalesce on a variable that can not be null will be an error in the next version. But in this version it does not. Bleeding edge gives you the features of the next PHPStan version, right now.

How to activate it

To start using bleeding edge, you need to include it in your phpstan.neon. The next time you run PHPStan, you will get all the new errors.

includes:
	- vendor/phpstan/phpstan/conf/bleedingEdge.neon

Why activate it

Updating composer dependencies should be part of the normal workflow of a team. Whether you take time every monday to do updates, or you update constantly. When using bleeding edge, you have a little bit of work whenever something new gets added. You need to fix the errors, or add them to an ignore. This is only one new rule or setting at a time, meaning you generally don’t have to spend all that much time.

When you wait until the next major version, you suddenly have maybe 10 new rules and settings you need to account for. Meaning you’ll have to spend a far bigger chunk of time then. This could also make it easier to just say “screw it”, and ignore all the new errors. By doing the updates as they come, you keep the tasks small.

You don’t need to be at level max in order to use bleeding edge. If a new rule gets added at level 7, and you are on level 5, that new rule wont activate.

When not to activate it

I would only suggest to do this for a project, with a composer.lock file. If you are creating a library, this could mean that suddenly a nightly build is failing, or that a PR of gets blocked as the new PHPStan errors need to be fixed first.

Even in a library, you could still run a check with bleeding edge, but allow it to fail. That way you still get the feedback that in the next version things will break, but it wont block contributions.

In summary

If your project uses PHPStan, use bleeding edge. It will make your upgrade path smaller, and allows you to use the features of the next version today.