Skip to content

Conversation

@johnny-mh
Copy link
Contributor

@johnny-mh johnny-mh commented Jun 1, 2025

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

@bolt-new-by-stackblitz
Copy link

Review PR in StackBlitz Codeflow Run & review this pull request in StackBlitz Codeflow.

@changeset-bot
Copy link

changeset-bot bot commented Jun 1, 2025

🦋 Changeset detected

Latest commit: a325600

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 2 packages
Name Type
@hey-api/openapi-ts Patch
@docs/openapi-ts Patch

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

@vercel
Copy link

vercel bot commented Jun 1, 2025

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name Status Preview Comments Updated (UTC)
hey-api-docs ✅ Ready (Inspect) Visit Preview 💬 Add feedback Jun 4, 2025 2:09pm

@codecov
Copy link

codecov bot commented Jun 1, 2025

Codecov Report

Attention: Patch coverage is 81.08108% with 7 lines in your changes missing coverage. Please review.

Project coverage is 21.80%. Comparing base (870e035) to head (a325600).
Report is 14 commits behind head on main.

Files with missing lines Patch % Lines
packages/openapi-ts/src/createClient.ts 16.66% 5 Missing ⚠️
packages/openapi-ts/src/patchSchemas.ts 93.54% 2 Missing ⚠️
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              
Flag Coverage Δ
unittests 21.80% <81.08%> (+0.12%) ⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
  • 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

@pkg-pr-new
Copy link

pkg-pr-new bot commented Jun 1, 2025

Open in StackBlitz

@hey-api/client-axios

npm i https://pkg.pr.new/hey-api/openapi-ts/@hey-api/client-axios@2117

@hey-api/client-fetch

npm i https://pkg.pr.new/hey-api/openapi-ts/@hey-api/client-fetch@2117

@hey-api/client-next

npm i https://pkg.pr.new/hey-api/openapi-ts/@hey-api/client-next@2117

@hey-api/client-nuxt

npm i https://pkg.pr.new/hey-api/openapi-ts/@hey-api/client-nuxt@2117

@hey-api/nuxt

npm i https://pkg.pr.new/hey-api/openapi-ts/@hey-api/nuxt@2117

@hey-api/openapi-ts

npm i https://pkg.pr.new/hey-api/openapi-ts/@hey-api/openapi-ts@2117

@hey-api/vite-plugin

npm i https://pkg.pr.new/hey-api/openapi-ts/@hey-api/vite-plugin@2117

commit: a325600

@mrlubos
Copy link
Member

mrlubos commented Jun 1, 2025

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',
Copy link
Member

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

Copy link
Contributor Author

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?

Copy link
Contributor Author

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

Copy link
Member

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

"commander": "13.0.0",
"handlebars": "4.7.8"
"handlebars": "4.7.8",
"immer": "10.1.1",
Copy link
Member

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?

Copy link
Contributor Author

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.

Copy link
Member

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?

Copy link
Contributor Author

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.

Copy link
Member

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',
Copy link
Member

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?

Copy link
Contributor Author

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.

Copy link
Member

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

Copy link
Contributor Author

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.

Copy link
Member

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

@johnny-mh johnny-mh force-pushed the add-fix-schema-plugin branch from f4d8e0a to 98eabb8 Compare June 3, 2025 17:48
@johnny-mh johnny-mh changed the title feat(fix-schema): add fix-schema plugin feat(fix-schema): add input.fix.schema feature Jun 3, 2025
@johnny-mh johnny-mh changed the title feat(fix-schema): add input.fix.schema feature feat: add input.fix.schema feature Jun 3, 2025
Copy link
Member

@mrlubos mrlubos left a 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
Copy link
Member

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 😳

Suggested change
| OpenApiSchemaObject.V4_0_X
| OpenApiSchemaObject.V3_0_X

Copy link
Contributor Author

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.

export default {
input: {
fix: {
schema: {
Copy link
Member

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?

Suggested change
schema: {
schemas: {

Copy link
Contributor Author

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.

```js [date-time to timestamp]
export default {
input: {
fix: {
Copy link
Member

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?

Suggested change
fix: {
patch: {

Copy link
Contributor Author

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.

const schema = fix.schema;

const processSchemas = (schemas: Record<string, any>) => {
for (const key in schemas) {
Copy link
Member

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

Copy link
Contributor Author

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?: {
Copy link
Member

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

Copy link
Contributor Author

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?

@johnny-mh johnny-mh force-pushed the add-fix-schema-plugin branch from 429c622 to a325600 Compare June 4, 2025 14:05
@johnny-mh johnny-mh changed the title feat: add input.fix.schema feature feat: add input.patch.schemas feature Jun 4, 2025
Copy link
Member

@mrlubos mrlubos left a 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!

@mrlubos mrlubos merged commit 7a2905b into hey-api:main Jun 4, 2025
15 checks passed
@github-actions github-actions bot mentioned this pull request Jun 4, 2025
@terijaki
Copy link

terijaki commented Jun 5, 2025

@johnny-mh the types seems to be missing for the config?

image

@mrlubos
Copy link
Member

mrlubos commented Jun 5, 2025

@terijaki not released yet! #2117 (review)

@terijaki
Copy link

terijaki commented Jun 5, 2025

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!

@mrlubos
Copy link
Member

mrlubos commented Jun 5, 2025

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!

@mrlubos
Copy link
Member

mrlubos commented Jun 5, 2025

@terijaki can't find your email from your profile so I'll say it here – thank you for sponsoring Hey API!

@johnny-mh johnny-mh deleted the add-fix-schema-plugin branch June 5, 2025 11:47
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