-
-
Notifications
You must be signed in to change notification settings - Fork 448
Find Firebase user(s) by federated user id #1000
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
base: 7.x
Are you sure you want to change the base?
Find Firebase user(s) by federated user id #1000
Conversation
The thousands PR, congrats! 😅🎊 Thank you for the contribution! I will have to find out how I can add this without breaking BC due to the changed interface, but that's a general problem 😕 |
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## 7.x #1000 +/- ##
=============================================
- Coverage 90.00% 50.04% -39.97%
- Complexity 1444 1447 +3
=============================================
Files 140 140
Lines 4184 4202 +18
=============================================
- Hits 3766 2103 -1663
- Misses 418 2099 +1681 🚀 New features to boost your workflow:
|
Okay, there are two ways I currently see without breaking BC or creating a new major release:
if ($auth instanceOf ProvidesUsersByProviderUid) {
$user = $auth->getUserByProviderUid($providerId, $providerUid);
}
if (method_exists($auth, 'getUserByProviderUid')) {
$user = $auth->getUserByProviderUid($providerId, $providerUid);
} I'm leaning towards (1), but the next added method then would need a new interface as well. So, I'm leaning towards (2), but asking users to What do you think? I need a solution for this in general. At the moment, each added method/feature is a breaking change and I'm just lucky this doesn't happen too often. |
I have to admit, until now I have never realised that adding new methods to an interface is actually a BC-break (but now I see why). I would strongly prefer the first option as it is way cleaner and intentions are pretty clear. I suppose the process for all those additional single-purpose-micro-interfaces could be like this:
A bit of maintenance, but for now I don't see an easier way out. Holding off any new methods until next major release seems like an overkill. So would you like me to split this of into a micro-interface? Any ideas for the naming? Would |
Thank you so much for the thought you've put into the problem, I agree with you 100%. Maintenance work is not a problem for me - I'd just have to remember, but perhaps that's a good opportunity to start using GitHub projects/milestones 😅 As for the naming, I agree as well, I've just been working with Laravel too much lately 🙈. Naming is hard - what if there's another Federated ID related methods coming up before the next major release 🤔. How would you feel about |
Yeah, that sounds great 👍 I'll do the update a little later |
This is a port of a method that is available in the official node.js sdk, implemented in the analogous way.