Skip to content
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

Fix finder compatibilty with 4.x #17659

Merged
merged 3 commits into from Apr 10, 2024
Merged

Fix finder compatibilty with 4.x #17659

merged 3 commits into from Apr 10, 2024

Conversation

markstory
Copy link
Member

We have rector rules to update the callsites of finders to use named parameters. What we lack is rector operations to upgrade finder declarations to use named parameters. Because this is an impossible task, we should have better compatibility for new style finder calls with old style options arrays. This helps improve finder ergonomics (less typing) for more folks.

This would have saved me a bunch of work when upgraded an application recently and making the upgrade smoother is important to me.

@markstory markstory added this to the 5.0.8 milestone Apr 9, 2024

$secondParamIsOptions = (
count($params) === 2 &&
$secondParam?->name === 'options' &&
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are there other variable names we should consider? The docs, app and bake all use options but there are likely other commonly used names.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Supporting only the "official" variable name should suffice IMO.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think only options is good. It's fairly standardized.

We have rector rules to update the callsites of finders to use named
parameters. What we lack is rector operations to upgrade finder
declarations to use named parameters. Because this is an impossible
task, we should have better compatibility for new style finder calls
with old style options arrays. This helps improve finder ergonomics
(less typing) for more folks.

This would have saved me a bunch of work when upgraded an application
recently and making the upgrade smoother is important to me.
Comment on lines -2686 to -2690
deprecationWarning(
'5.0.0',
'Using options array for the `find()` call is deprecated.'
. ' Use named arguments instead.'
);
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think this should be deprecated right now. It creates a lot of noise to deal with when upgrading. If others feel strongly about this I'm happy to put it back.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If we don't push people to update the methods they will very likely continue using the same and removing this temporary support will become difficult even for the next major.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fair point, I can add this deprecation back.

@markstory markstory merged commit b2b5580 into 5.x Apr 10, 2024
10 checks passed
@markstory markstory deleted the fix-finder-compat branch April 10, 2024 14:55
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants