components.parameters.region.schema.enum does not contain 'en' which is the default value in openapi3 spec

[WORMSS]

components.parameters.region.schema.enum does not contain 'en' which is the default value

located in the openapi3 spec

/dist/google-maps-platform-openapi3.json

Seems I can't link directly to the file for ease of use, because Github thinks the file is too big.

Should be around line 28303-28558

[jpoehnelt]

Thanks for catching this! I'll get a fix out right away. Do you mind sharing how you are using the Open API spec or the various outputs that lead you to this bug? Thanks again!

[WORMSS]

Ran it against https://github.com/ferdikoomen/openapi-typescript-codegen
it tried to do region = 'en' but 'en' was an invalid input

[jpoehnelt]

Got it. Any other issues with codegen? I'm looking to eventually generate and publish some libraries from this.

[WORMSS]

But.... I actually had to fix a bug in the repo, since their version couldn't handle the ~1 for path argument in references... so see ferdikoomen/openapi-typescript-codegen#824 for my hack/fix

[jpoehnelt]

I could add a dereferenced (resolve all $ref) spec if that seems to be an issue with codegens.

[github-actions]

🎉 This issue has been resolved in version 1.16.20 🎉

The release is available on:

• v1.16.20
• GitHub release

Your semantic-release bot 📦🚀

[WORMSS]

Could do. I personally think the codegens should be able to deal with the spec correctly.. I've found others which can..

The only issue is that the naming of the endpoints were really bad.. Like.. REALLY bad.. after it got spit out of the codegen.

End endpoints ended up being like

getPlacesApiService()
getPlacesApiService1()
getPlacesApiService2()
getPlacesApiService3()
getPlacesApiService4()

instead of something useful like

getPlacesTextSearch()
getPlacesDetails()

etc etc

I am unsure if that is an issue with the openapi-typescript-codegen or the spec file though. I would have to check that particular issue with other tools and see what they spit out..
Since you correctly tagged similar apis such as places/roads/streetview.. I would presume you are doing things right.

I know it handles our own api correctly, but I have not done a side by side to know 'how' these codegens decide the names of the functions

[jpoehnelt]

Seems I could improve that with operationId although the fallback in the could also be improved. https://github.com/ferdikoomen/openapi-typescript-codegen/blob/830b317d0a0f6aaa97dba43818ce6d1ccc109be2/src/openApi/v3/parser/getOperation.ts#L22-L23

[WORMSS]

It would seem you hit it perfectly..
our API has "operationId": "Card_CardAccessAdvisorByRole", and the function does seem to indicate this is what it would output if you remove non alphanumerics and run a run camelcase on it would result in cardCardAccessAdvisorByUser and that is exactly what we get.
the cardCard in our codebase is a little undesirable, but nothing to cry too much about...

Good spot with getOperation