-
-
Notifications
You must be signed in to change notification settings - Fork 173
Typeid support #2034
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: main
Are you sure you want to change the base?
Typeid support #2034
Conversation
|
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
@hey-api/client-axios
@hey-api/client-fetch
@hey-api/client-next
@hey-api/client-nuxt
@hey-api/nuxt
@hey-api/openapi-ts
@hey-api/vite-plugin
commit: |
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #2034 +/- ##
==========================================
- Coverage 22.64% 22.59% -0.05%
==========================================
Files 252 252
Lines 21475 21524 +49
Branches 818 818
==========================================
+ Hits 4862 4863 +1
- Misses 16607 16655 +48
Partials 6 6
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
See #2033
This is a very rough draft. I originally tried to use the
x-typeid-type
property I proposed in jetify-com/typeid#45. Then I noticed there's an IR involved and decided to temporarily extract the type name from theexample
field instead (which I also had to add to the parsers/IR).I've tested this by modifying the
openapi-ts-fetch
example. I downloaded the openapi.yml file and modified theid
property ofOrder
to be a typeid like this:And added
typeids: true,
to theopenapi-ts.config.ts
file.This produced this output:
Nice 🎉
Currently the TypeID declaration is always added. Which means if you enable the config option but don't use typeids, you'll get an unused type warning.
Questions
x-typeid-type
instead of parsing theexample
value, but I'm unsure given the current IR infrastructure. I don't believe adding arbitrary extensions to the parser is maintainable. One I had was: what if the IR had an extra field which simply contained the original object or justx-*
properties? This feels more future-proof to me.TypeID<T>
be exported or should consumers doUser["id"]
instead ofTypeID<"user">
if they want to access the type themselves?type UserID = "user_${string}"
) instead of theTypeID
"overlord" (or maybe both)? This would require extending the "State" interface to keep track of already generated ID types