Skip to content

Introduce Valinor for type-safe object mapping #1009

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

Merged
merged 2 commits into from
Jul 21, 2025
Merged

Introduce Valinor for type-safe object mapping #1009

merged 2 commits into from
Jul 21, 2025

Conversation

jeromegamez
Copy link
Member

@jeromegamez jeromegamez commented Jul 13, 2025

Introduce Valinor for type-safe object mapping. The first application is mapping a given service account file, JSON, or array to the newly added internal ServiceAccount class, with more to follow in future releases.

:octocat:

Copy link

codecov bot commented Jul 13, 2025

Codecov Report

Attention: Patch coverage is 81.10236% with 24 lines in your changes missing coverage. Please review.

Project coverage is 89.60%. Comparing base (53edaa9) to head (f410f49).
Report is 2 commits behind head on 7.x.

Additional details and impacted files

Impacted file tree graph

@@             Coverage Diff              @@
##                7.x    #1009      +/-   ##
============================================
- Coverage     90.46%   89.60%   -0.86%     
- Complexity     1451     1477      +26     
============================================
  Files           140      146       +6     
  Lines          4238     4330      +92     
============================================
+ Hits           3834     3880      +46     
- Misses          404      450      +46     
🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

@romm
Copy link

romm commented Jul 13, 2025

Some minor comments, but overall LGTM! 👍

@romm
Copy link

romm commented Jul 13, 2025

Just saw that the review was not submitted 🤦

@jeromegamez
Copy link
Member Author

Great feedback, thanks so much! I'll make sure to implement your suggestions once I get back at my desk!

@jeromegamez jeromegamez force-pushed the use-valinor branch 2 times, most recently from b2efe14 to c5dcd7e Compare July 13, 2025 22:22
@jeromegamez jeromegamez changed the title Use Valinor Integrate cuyz/valinor for type-safe (de)serialization Jul 13, 2025
@romm
Copy link

romm commented Jul 21, 2025

Hi @jeromegamez just wanted to make sure if everything is fine on your side, or you need some help regarding the integration of the mapper? Have a good day!

@jeromegamez
Copy link
Member Author

Everything is fine, thanks a lot for asking! I'm just short on time and contemplating if I should leave it with this to introduce it in the first place or if I should wait until I have migrated all the other value objects first - but mostly short on time 😅

@romm
Copy link

romm commented Jul 21, 2025

Alright, no worries!

I'd recommend releasing it with just a few DTO in the first place. This way, if anything goes badly for end-users (we never know) it will be easier to fix the issues. But your decision, of course. 😊

@jeromegamez
Copy link
Member Author

YOU'RE JUST HERE FOR THE DOWNLOADS!!! 😂

@romm
Copy link

romm commented Jul 21, 2025

I'd be lying if I said I'm not 😁! I'm mostly interested in seeing if this works fine with a big user base, though. 😛

But I'd have given the same advice anyway! 😅

@jeromegamez jeromegamez changed the title Integrate cuyz/valinor for type-safe (de)serialization Introduce Valinor for type-safe object mapping Jul 21, 2025
@jeromegamez
Copy link
Member Author

@romm What I meant to ask - would something like https://github.com/kreait/firebase-php/blob/f410f49f2209ccfb105d02cc39041d594bf89dbe/src/Firebase/Valinor/Source.php make sense to integrate into Valinor by default for the JSON Source?

@jeromegamez jeromegamez merged commit 04b739e into 7.x Jul 21, 2025
14 of 15 checks passed
@jeromegamez jeromegamez deleted the use-valinor branch July 21, 2025 11:18
@romm
Copy link

romm commented Jul 21, 2025

@romm What I meant to ask - would something like f410f49/src/Firebase/Valinor/Source.php make sense to integrate into Valinor by default for the JSON Source?

I see the value it can bring, however I'm more of an "explicit coding" type of guy, most of the time, so I'd prefer users to use existing Source::* methods.

Also, JSON values can start with [, if you also want to support JSON lists in your own Source::parse() method. 😊

@jeromegamez
Copy link
Member Author

Oh, good point, I will add this, thank you!

@jeromegamez
Copy link
Member Author

Released with 7.21.0 🤗

@romm
Copy link

romm commented Jul 24, 2025

🚀

I should have a bit more spare time in the upcoming days, do not hesitate to ping me if any issue related to the mapping/normalization occurs, I could probably help!

Also, it just occurred to me (missed it during the review) that no cache is used: do you plan to use it at some point? Do you already use cache in other parts of the library?

Anyway, thanks for keeping me updated!

@jeromegamez
Copy link
Member Author

That was on purpose - I think we discussed this on Mastodon, but I don't remember (if there was) a conclusion... 😅

I wanted to be sure that this wouldn't break production for projects using read-only filesystems, for example on AWS ECS (I have first-hand experience there) or cloud functions (with Bref).

Concerning cache - the SDK comes with a PSR-16 Memory Cache only, but others can be configured with the factory, including the mapper and normalizer cache - I did forget to update the docs, though, I think 😬

@romm
Copy link

romm commented Jul 24, 2025

Indeed, I forgot about that, it makes sense. People who need better performance can always inject the cache themselves I guess. Updating the docs could be nice indeed. 😊

}

try {
return new self(BaseSource::file(new SplFileObject($value)));

Choose a reason for hiding this comment

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

Just want to highlight that this was a small breaking change for us, because files are now expected to have a .json, .yaml or .yml extension, and this wasn't required before. Maybe an edge case, because of the way we provision config in our projects. We ended up simply reading the file ourselves before passing it to the lib.

Copy link
Member Author

@jeromegamez jeromegamez Jul 30, 2025

Choose a reason for hiding this comment

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

Oh, shoot, I'm sorry! How do you provision the config? Perhaps I can adapt the SDK to other file types and formats.

Update: Is it just™ the file extension?

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'm addressing this in #1013 - I hope this will restore the previous behavior for you! 🤞🏻

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.

3 participants