-
-
Notifications
You must be signed in to change notification settings - Fork 272
feat: add input.patch.schemas feature
#2117
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
Conversation
|
|
🦋 Changeset detectedLatest commit: a325600 The changes in this PR will be included in the next version bump. This PR includes changesets to release 2 packages
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #2117 +/- ##
==========================================
+ Coverage 21.67% 21.80% +0.12%
==========================================
Files 268 269 +1
Lines 24666 24802 +136
Branches 837 859 +22
==========================================
+ Hits 5347 5408 +61
- Misses 19313 19388 +75
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:
|
a37d0f8 to
f4d8e0a
Compare
@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: |
|
Hey @johnny-mh, this is nice work! I sent you an email, would like to chat through this a bit |
| output: 'src/client', | ||
| plugins: [ | ||
| { | ||
| name: 'fix-schema', |
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.
The main question I have for now is why did you decide to go with a separate plugin vs maybe making this an option in input? My understanding is you're manipulating the Hey API intermediate representation model in the plugin, whereas you could work directly with the OpenAPI spec in input
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.
I understood that the Intermediate Representation serves as an interface to unify the differences between various OpenAPI versions.
Rather than having fix-schema plugin users write fix functions that need to be implemented differently for each OpenAPI version, I wanted them to be able to utilize a consistent interface.
However, if you're concerned about the Intermediate Representation being modified, I can refactor this to incorporate the functionality into config.input.fix as you mentioned.
What do you think?
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.
Please let me know which approach you prefer, and I'll implement it that way
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, no need. I'm just curious about your thinking because I'll want to update the docs somewhat and understand this feature better. What you have works
packages/openapi-ts/package.json
Outdated
| "commander": "13.0.0", | ||
| "handlebars": "4.7.8" | ||
| "handlebars": "4.7.8", | ||
| "immer": "10.1.1", |
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.
There's something not feeling right about adding 2 new dependencies for a plugin most people might never use. Are these dependencies crucial? Is there a way we could implement the needed functionality ourselves? How much effort would that involve?
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.
The two packages are not crucial dependencies. I included them primarily to enhance the convenience of using this plugin.
If we change the implementation to only accept functions for spec modifications, we can eliminate the need for both packages entirely. We could then handle this by documenting guidance for users to incorporate these packages as needed when implementing their spec modification functions.
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.
How would this affect developer experience? On the surface it sounds good to me, any reason we wouldn't want to do away with the dependencies?
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.
I added the json-patch package to enable writing modification functions concisely. However, I think it would be fine to have users write their own functions or let them use whatever packages they need within those functions.
As for immer, I actually added it because I wasn't sure if directly modifying the Intermediate Representation would be okay. Now I'm thinking that if we're modifying within the input, it would similarly be unnecessary.
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.
To conclude this thread, my preference would be to go dependency-free and let users bring their own if they need
| _dependencies: [], | ||
| _handler: handler, | ||
| _handlerLegacy: () => {}, | ||
| name: 'fix-schema', |
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.
I'm assuming you built this because you have an actual use case. Is it a common use case for you? Or it happened only with one specification and you've decided to build this plugin?
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.
I have collaborated with multiple backend developers who provide Swagger specifications. While some backend developers carefully write their Swagger documentation, in some organizations, they only write brief descriptions due to business schedule constraints, or sometimes provide them in completely incorrect formats.
Additionally, while some backend framework plugins for writing Swagger properly follow the OpenAPI specification, there are frameworks that fail to do so.
Whenever I encountered such situations, it was often difficult to communicate with backend developers and request modifications to the Swagger JSON. In these cases, this feature proved to be extremely useful.
For reference, this use case is included in the plugin usage guide that's part of the PR.
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.
I actually didn't look at the implementation thoroughly. How do you ensure this plugin runs before everything else? Assuming that's what happens so other plugins work with the patched spec
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.
That's why I added a note in the guide documentation to specify this plugin's order at the very front. But as you suggested, if we handle it directly in the input, we wouldn't need such precautions. I'll try implementing it that way.
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.
Yeah I guess this feels more like a feature than plugin, so making it an option on input could be more intuitive. It really is something akin to the filters feature except you're patching the schema. I'm not against making it operate on the raw spec btw, that's what filters do as well. Presumably you know what the spec looks like if you're trying to modify it
f4d8e0a to
98eabb8
Compare
input.fix.schema feature
input.fix.schema featureinput.fix.schema feature
98eabb8 to
f4694a5
Compare
mrlubos
left a comment
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.
It's starting to look pretty polished! Did you try this modified pull request in your repository? Still works okay?
| ( | ||
| schema: | ||
| | OpenApiSchemaObject.V2_0_X | ||
| | OpenApiSchemaObject.V4_0_X |
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.
How is this not throwing anywhere 😳
| | OpenApiSchemaObject.V4_0_X | |
| | OpenApiSchemaObject.V3_0_X |
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.
Yeah, weird that it's not throwing! Fixed it anyway.
docs/openapi-ts/configuration.md
Outdated
| export default { | ||
| input: { | ||
| fix: { | ||
| schema: { |
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.
Let's keep the naming consistent with OpenAPI?
| schema: { | |
| schemas: { |
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.
Sounds good, I'll fix that.
docs/openapi-ts/configuration.md
Outdated
| ```js [date-time to timestamp] | ||
| export default { | ||
| input: { | ||
| fix: { |
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.
What do you think about calling this patch?
| fix: { | |
| patch: { |
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.
That sounds good to me. I'll make the changes.
packages/openapi-ts/src/fixSchema.ts
Outdated
| const schema = fix.schema; | ||
|
|
||
| const processSchemas = (schemas: Record<string, any>) => { | ||
| for (const key in schemas) { |
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.
It would be more efficient to loop through fix objects as they'll be always smaller (or equal) to schemas objects
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.
That's a great point! Thanks for catching that.
| include?: ReadonlyArray<string>; | ||
| }; | ||
| }; | ||
| fix?: { |
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.
Please add a JSDoc comment about this feature so people don't have to go to docs
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.
I just added it. How does it look?
429c622 to
a325600
Compare
input.fix.schema featureinput.patch.schemas feature
mrlubos
left a comment
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.
Looks good! Let's release it tomorrow. Thank you so much!
|
@johnny-mh the types seems to be missing for the config? |
|
@terijaki not released yet! #2117 (review) |
|
Oh my bad. It’s already in the docs and since I am on the latest 0.70.0 I thought I am good to go. 😊 Definitely looking forward to the feature! |
|
Yeah, the docs pipeline should be improved at some point to prevent this. I'm always surprised when people find out so quickly, it's been only a few hours! Will push it later today! |
|
@terijaki can't find your email from your profile so I'll say it here – thank you for sponsoring Hey API! |

Add new
input.patch.schemasfeature - Implement functionality to modify OpenAPI schema definitions during code generation process