codegen: Add exactOperationIds option to generateEndpoints config#5174
codegen: Add exactOperationIds option to generateEndpoints config#5174issy wants to merge 16 commits intoreduxjs:masterfrom
exactOperationIds option to generateEndpoints config#5174Conversation
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.
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.
There was a problem hiding this comment.
Interesting. So outputFile → void, and no outputFile → string, correct? If that's expected behavior, the types should reflect it more cleanly. I'll open a small follow-up PR for this. Thanks for flagging!
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.