-
Notifications
You must be signed in to change notification settings - Fork 56
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
feat: add TransferTypes plugin for Generator #3171
base: main
Are you sure you want to change the base?
Conversation
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #3171 +/- ##
==========================================
+ Coverage 92.65% 92.74% +0.08%
==========================================
Files 85 85
Lines 3187 3183 -4
Branches 778 776 -2
==========================================
- Hits 2953 2952 -1
+ Misses 182 179 -3
Partials 52 52
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. |
# Conflicts: # package-lock.json
# Conflicts: # package-lock.json
@@ -48,6 +48,8 @@ public final class TransferTypesPlugin | |||
classMap.put(JsonNode.class.getName(), Object.class); | |||
classMap.put(ObjectNode.class.getName(), Object.class); | |||
classMap.put(ArrayNode.class.getName(), List.class); | |||
classMap.put("org.springframework.web.multipart.MultipartFile", |
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.
With the added spring-web
dependency, is there a reason not to use the MultipartFile.class.getName()
instead of the string literal version of the class name?
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.
Hmm... Good question. Actually, I just followed the approach for other Spring classes in this file. Should we reconsider this approach?
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.
Though, changed / added a lot of files, most of the changes were mechanical replacements of types, or changes in the signature of the internal functions, so LGTM!
However, requested changes for the sake of the questions I asked.
@@ -56,7 +56,7 @@ | |||
"@vaadin/hilla-generator-utils": "24.7.0-alpha8", | |||
"fast-deep-equal": "^3.1.3", | |||
"openapi-types": "^12.1.3", | |||
"typescript": "5.7.3" | |||
"typescript": "^5.6.2" |
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.
specific reason for the downgrade?
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.
Nope, just a mistake, thanks!
Quality Gate passedIssues Measures |
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.
Removal of ReadonlyDeep
and addition of the TransferTypes
plugin would have deserved separate PRs. Other changes, like the switch to vitest
in i18n
hardly correlate with this PR.
Yes, I agree with that part. It was just created some issues when I worked with the plugin, so I decided to change it, and my issues were resolved.
Erm... Didn't get it. This PR is about adding that plugin, isn't it?
Agree but CI continued failed because of various weird issues, so to reduce the time spent on debugging these issues, I just decided to do the planned replace. |
No description provided.