-
-
Notifications
You must be signed in to change notification settings - Fork 1.3k
codegen: Add exactOperationIds option to generateEndpoints config
#5174
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: master
Are you sure you want to change the base?
Conversation
Review or Edit in CodeSandboxOpen the branch in Web Editor • VS Code • Insiders |
|
This pull request is automatically built and testable in CodeSandbox. To see build info of the built libraries, click here or the icon next to each commit SHA. Latest deployment of this branch, based on commit 561ce40:
|
✅ Deploy Preview for redux-starter-kit-docs ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
| export async function generateEndpoints(options: GenerationOptions & { outputFile: string }): Promise<void>; | ||
| export async function generateEndpoints(options: GenerationOptions & { outputFile?: never }): Promise<string>; |
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 also including this slightly off-topic change here. This allows the return type of the function (string or void) to be inferred based on whether outputFile is passed. Without this, I have to do await generateEndpoints(...) as string in my codegen setup.
Currently,
@rtk-query/codegen-openapiconverts operation IDs to camelCase before generating API code. This is due to an implementation detail inoazapfts(see oazapfts/oazapfts#591). For example, if your operation ID isfetchMyJWTPleaseit will be renamed tofetchMyJwtPlease.Although this is documented behaviour, it is not always desired behaviour for library consumers. I think it would be good to offer users an escape hatch from that behaviour. In this PR I am introducing the config property
exactOperationIds?: boolean. When enabled, it will not transform any operation IDs. This comes with some additional checks to ensure that there are no missing/duplicate operation IDs, but I think it's acceptable with such an escape hatch that users should be expected to validate these things.I have added a small section to the docs to reflect this:

I believe this should resolve the following issues:
#4322
#2181
#2675
Ideally this would be implemented in
oazapfts. There are plans on the roadmap for a plugin system and a hook for naming/renaming operations. This would be ideal for a future refactor, but will have to wait until that work is completed on their side.