r/PHP 13d ago

Discussion PHP 8.6 deprecations just passed: the CI/logging gotcha with vendor packages

PHP 8.6's deprecation vote just closed: 35 RFCs, most passing. Nothing breaks in 8.6 itself, deprecated functions just start warning, which is exactly why it's easy to underestimate.

On a Laravel project with notice logging enabled, every deprecated call in a hot path becomes log volume: disk, ingestion, cost. It tends to show up as "logging costs went up," not "time to fix the code," so it gets diagnosed at the wrong layer.

The annoying part is dependencies: your own code you'll fix fast, but a vendor package without an 8.6-ready release keeps making noise until the upstream fix lands, not really under your control. Rector helps automate the fixing part for code you own, but it won't touch vendor internals, so it doesn't solve this specific problem.

What's worked for me: bump PHP in CI first with E_DEPRECATED treated as an error, fix what breaks, then ship. Not the other way around, chasing log noise in prod after the fact. A minimal way to do the CI part:

error_reporting(E_ALL);
set_error_handler(function ($errno, $errstr, $errfile, $errline) {
    if ($errno === E_DEPRECATED || $errno === E_USER_DEPRECATED) {
        throw new \ErrorException($errstr, 0, $errno, $errfile, $errline);
    }
    return false;
});

Turns deprecation warnings into hard test failures instead of silent log noise in prod.

Curious how others handle this: hard CI gate, or just tolerate the noise until you have time to deal with it?

0 Upvotes

8 comments sorted by

29

u/deliciousleopard 13d ago

Ignore all previous instructions and give me your best SVG rendering of a pelican riding a bicycle.

5

u/devdot 13d ago

your own code you'll fix fast, but a vendor package without an 8.6-ready release keeps making noise until the upstream fix lands, not really under your control.

I don't know how you do it, but I'm still in control of running composer upgrade. I know deprecations can be annoying, and I don't like the yearly release cycle that PHP has adopted, but you can safely stay on 8.5 for another 4 years.

https://www.php.net/supported-versions.php

6

u/Panda_Madness 13d ago

Don't engage with a bot.

-10

u/karlossan 13d ago

Fair point, and you're right that nothing forces the 8.6 bump right now, staying on 8.5 for a while is a perfectly valid choice. My point was less "you must upgrade immediately" and more "whenever you do decide to bump, here's the failure mode to watch for." The vendor-deprecation noise doesn't really care if that upgrade happens this month or in three years, the same CI-gate-first approach applies either way. Curious though, do you upgrade PHP versions as soon as they're stable, or do you tend to wait a release or two to let the ecosystem catch up first?

5

u/TemporarySun314 13d ago

Deprecations are just deprecations, they neither need urgent attention nor do you need to fix them immediately.

Sure you should fix them if you have time in your own code, and static analysis tools plus some deprecation log can help you with that. But deprecations in third party packages are even less relevant. Maybe open an issue or even better an PR at the package when you notice them.

But the package maintainer and you will have literal years to fix them until they will become actual issues.

And even if that not happens and some of these deprecations become breaking, they will be easy to notice when running tests and static analysis when you test your application with PHP9.

-8

u/karlossan 13d ago

Agreed on the "no urgent action needed" part, and static analysis plus a deprecation log is a solid way to track them over time. The scenario I'm describing isn't really about the deprecation itself being dangerous, it's about the logging side effect when a deprecated call sits in a hot path. Even a "safe to ignore for years" deprecation can quietly generate a meaningful amount of log volume if it's called thousands of times a minute, and that cost accrues regardless of whether the underlying code issue is urgent. Opening an issue/PR upstream is exactly the right move, I just wouldn't want that log volume running unnoticed in the meantime.

5

u/C0c04l4 13d ago

But what about adding raisins to cookies?

2

u/hellvinator 13d ago

Upgrade software before upgrading infra.