- Sponsor
-
Notifications
You must be signed in to change notification settings - Fork 264
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fixes for implicit nullability deprecation #1152
Fixes for implicit nullability deprecation #1152
Conversation
Uh nice, thanks, I just added also 8.4 to CI via #1153 AFAIK this will require a major version bump, as the signature changes will break ones extending any of these classes/methods. But I am also curious: how can we make them "visible"? In my 8.4 PR there's no deprecation emitted anywhere (at least not from this library). Do we have to enable this somewhere? |
We're using PHPUnit's When you get it working, you'll likely see a lot of deprecation warnings from |
@duncanmcclean I just merged #1154 , can you give it a try with your PR, if we see the deprecations now? Or, rather: if we see some reduced, my PR makes them visible. But OTOH might though to spot in the logs as there are so many emitted… (As in: can you merge master again into your PR, I'll then kick of the workflow trigger finally) |
Done! |
It's green, that's good. But now that I looked closer, comparing the master run e.g. https://github.com/rebing/graphql-laravel/actions/runs/11916496933/job/33209292621 with this one https://github.com/rebing/graphql-laravel/actions/runs/11916994210/job/33211713836?pr=1152 , already in the master version I don't see deprecations from the code being changed here 🤔 (because if we don't see them, how can we make sure to fix them all [except running in some external project]) |
I originally ran ino these deprecation warnings when running our own test suite:
Then, locally, when I pulled down As for the others, I didn't actually see those deprecation warnings first-hand but thought they might be worth fixing at the same time... I would have thought they'd show up in PHPUnit though 🤔 |
Thanks, that helps. I hope I'll find time to dig a bit deeper here. |
For some reason when running code via phpunit it in fact does not emit any deprecations from this library (except from test classes). But when use just
This is from master; and with your branch I don't get them 👍🏼 So: what is phpunit doing here with the code in |
Hmm, that's strange. 🤔 |
On a greenfield phpunit project I did locally, deprecations automatically show up as To see the actual message it requires I also checked Basically, all we (probably) should need to know is laid out on https://docs.phpunit.de/en/10.5/error-handling.html#limiting-issues-to-your-code Something somewhere must be messing with the settings or so. |
I finally figured it out, or at least some things -> master now contains #1155 which shows the deprecations. Laravel takes over this stuff, that's why regular phpunit config does not really help much here; at least this is my understanding. Can you please merge master once more? |
Oh, that's interesting. I guess it sorta makes sense in an app context, but I suppose it's not that helpful in the context of a package.
Done 🙂 |
Nice, yes I see them gone. Now I can finally get onto the review how to proceed after I take a break 😅 |
Gotta love debugging your test suite 🫠 |
Related to this issue - the The PR to fix them (thecodingmachine/safe#441) has been open for a while now, but unfortunatley, it doesn't look like the maintainers are actively looking at issues or pull requests. 😞 What are your thoughts on potentially using a forked version of the |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the PR and your patience!
To me it was important to find a reliable way to be sure we fix all them and/or they don't come back with other accidental changes.
I tried improving things with a couple of PRs (#1153 , #1154 , #1155) but wasn't satisfied it finds all the cases. I finally found salvation with #1156 : phpstan on 8.4 seems most reliable to uncover this particular deprecation, as AFAICS it also finds cases not covered in this PR.
In #1152 (comment) I wrote
AFAIK this will require a major version bump, as the signature changes will break ones extending any of these classes/methods.
After reading https://php.watch/versions/8.4/implicitly-marking-parameter-type-nullable-deprecated and doing some tests I found out this is not true, so there's no BC concern.
TL;DR: will proceed merging this, handle potential leftovers in #1156 and it fall good, try to roll a release ASAP.
Thanks 🙏🏼
Regarding this matter:
Thanks, I've written my thoughts over at thecodingmachine/safe#441 (comment) ! |
Thank you for looking at this PR so quickly! 🙂 I've subscribed to the issue on the |
Summary
Implicitly nullable parameter declarations have been deprecated in PHP 8.4.
This pull request fixes that by explicitly declaring nullable parameters, preventing deprecation warnings.
Type of change:
Checklist:
composer fix-style