On Tue, Nov 30, 2021, at 10:17 PM, Brady Wetherington via internals wrote: >>>> …It's been merged to master, so you could stand up a build now and point >>>> to the many deprecation warnings you're expecting. I'm not saying send >>>> PRs to fix them all, just show real impact rather than theoretical >>>> guessing. … >> >> >> That’s a totally fair ask, and I’ll try and get that done and report back. I >> think I’m probably going to run into some Laravel problems here, as they >> only _just_ came up with a version that will run under php 8.1. I’ll get as >> far as I can and let you know - even if I determine that my suspicions were >> completely incorrect :) > > Okay - good news/bad news/good news - > > Good News: I managed to snag an 8.2 build and ran Snipe-IT on it, and > it worked completely fine. I cheated a little bit - I didn't try to > make a composer.json that would support 7.4 through 8.2, I just did a > 'composer install' from PHPv8, and then switched PHP versions out from > under it. Literally nothing broke at all - I was completely shocked! I > was so worried that I wasn't testing it right that I had to make a > quick little test script with dynamic properties in order to force the > deprecation warning to show up - and it did, so I *do* have the > latest. > > Bad News: That's because later versions of Laravel dump all > deprecation warnings straight to /dev/null by default. If you > configure a log 'channel' for 'deprecations', *then* you get actual > results. One page load (our dashboard page) generated 267KB of > deprecation warnings. Clicking through most of the main pages of our > app generated around 3.5MB of them. And these aren't full > stack-traces, they're just messages like: > > "[2021-12-01 03:48:23] local.WARNING: Creation of dynamic property > Illuminate\Database\MySqlConnection::$readWriteType is deprecated in > /Users/uberbrady/Documents/grokability/snipe-it/vendor/laravel/framework/src/Illuminate/Database/Connection.php > on line 1368" > > Good News: *Many many many* of those deprecation warnings were repeats > of the same deprecated thing from the exact same place. And *very very > few* were from the dynamic properties thing. *None* of the dynamic > properties deprecations were from our code. Everything was from > composer dependencies, and only a small handful - so, probably pretty > easy to remediate when it comes to that. > > So the _other_ deprecation notices are a whole other thing, and having > so many is definitely a drag, but that's a completely separate issue > from this dynamic properties thing, which doesn't seem too bad so far, > for us at least. Other folks might not get off so easily, and > /dev/null-ing deprecation warnings seems like it's kicking the can > down the road, but, well, *we're* OK for 8.2. > > I should note that a lot of my PHP-based CLI tools are spewing > deprecations everywhere as well, but they at least still work so I can > perhaps live with that. > > -B.
Thanks for the follow up! Out of curiosity, since it sounds like the dynamic props deprecation rates a "meh" on the problem scale for you, what is the most common other deprecation you're hitting? It would be interesting to see how many *unique* deprecation warnings a large, real-world application has and compare with other projects. --Larry Garfield -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
